Only one client can access a readonly database [CORE2018]

[firebird-automations]

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]

Commented by: @dyemanov

Are you sure it works with v2.0.3 Classic?

[firebird-automations]

Commented by: Guido Maucher (guma)

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

[firebird-automations]

Modified by: @dyemanov

assignee: Vlad Khorsun [ hvlad ]

[firebird-automations]

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]

Modified by: @hvlad

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

resolution: Fixed [ 1 ]

Fix Version: 2.5 Beta 1 [ 10251 ]

[firebird-automations]

Modified by: @pcisar

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

[firebird-automations]

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.