Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Only one client can access a readonly database [CORE2018] #2455

Closed
firebird-automations opened this issue Jul 28, 2008 · 7 comments
Closed

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Guido Maucher (guma)

Multiple access to a READONLY database (dialect 3, ODS > 10.) is not possible -> application hang-up.
Readonly is set by a batch using gfix.exe -mode read_only. Same problem exists with classic and superserver 2.1.0 and 2.1.1.
Using the same application with firebird 2.0.3 or 2.5 beta it works.
What can be the problem?

Commits: ea9555d a3d266b

====== Test Details ======

Restored database contains GTT. According to CORE3399 we can write in it even in read-only database.
This GTT serves as temp buffer for output row (we can not use windowed function in 2.5)

NB: for CLASSIC mode each ES/EDS will increase value of current_connection by 2, for SS/SC - by 1.
In order to avoid dependency of architecture it was decided to accumulate _SEQUENTIAL_ numbers
of connection IDs (i.e. without holes) in GTT and ouput all of them after loop finish.
This sequential order can be easy achieved in 3.0 using dense_rank() but in 2.5 we need to
write SQL with additional subquery.

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

Are you sure it works with v2.0.3 Classic?

@firebird-automations
Copy link
Collaborator Author

Commented by: Guido Maucher (guma)

I just tried it again: v2.0.3 Classic is fine.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

assignee: Vlad Khorsun [ hvlad ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

When new attachment\transaction started, engine creates lock using this att\tx's ID as a key. This new IDs derives from numbers stored on header page. For readonly databases this numbers incremented but never written back to the header page. Thus SS worked ok while two different processes of CS got the same numbers and then wait in lock manager indefinitely.

Solution is to introduce common database-wide counter in shared memory. All processes of CS is able to assign att\tx ID's using this common counter and don't conflict with each other.

Such counter is implemented using existing lock manager facilities.

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 2.5 Beta 1 [ 10251 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Closed [ 6 ] => Closed [ 6 ]

QA Status: Done successfully

Test Details: Restored database contains GTT. According to CORE3399 we can write in it even in read-only database.
This GTT serves as temp buffer for output row (we can not use windowed function in 2.5)

NB: for CLASSIC mode each ES/EDS will increase value of current_connection by 2, for SS/SC - by 1.
In order to avoid dependency of architecture it was decided to accumulate _SEQUENTIAL_ numbers
of connection IDs (i.e. without holes) in GTT and ouput all of them after loop finish.
This sequential order can be easy achieved in 3.0 using dense_rank() but in 2.5 we need to
write SQL with additional subquery.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants