Issue Details (XML | Word | Printable)

Key: CORE-2018
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Vlad Khorsun
Reporter: Guido Maucher
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Only one client can access a readonly database

Created: 28/Jul/08 12:59 PM   Updated: 28/May/15 03:05 PM
Component/s: Engine
Affects Version/s: 2.1.0, 2.1.1
Fix Version/s: 2.5 Beta 1

Environment: Windows XP SP3, own Delphi application created with IBObjects

QA Status: Done successfully
Test Details:
Restored database contains GTT. According to CORE-3399 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.


 Description  « Hide
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?



 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Dmitry Yemanov added a comment - 30/Jul/08 05:03 AM
Are you sure it works with v2.0.3 Classic?

Guido Maucher added a comment - 30/Jul/08 06:03 AM
I just tried it again: v2.0.3 Classic is fine.

Vlad Khorsun added a comment - 14/Oct/08 06:10 AM
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.