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-issue-importer opened this issue Jul 28, 2008 · 7 comments
Closed

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

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

Comments

@firebird-issue-importer

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-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 30, 2008

Commented by: @dyemanov

Are you sure it works with v2.0.3 Classic?

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 30, 2008

Commented by: Guido Maucher (guma)

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

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Sep 16, 2008

Modified by: @dyemanov

assignee: Vlad Khorsun [ hvlad ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Oct 14, 2008

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-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Oct 14, 2008

Modified by: @hvlad

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

resolution: Fixed [ 1 ]

Fix Version: 2.5 Beta 1 [ 10251 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Nov 8, 2009

Modified by: @pcisar

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

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented May 28, 2015

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
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants