Issue Details (XML | Word | Printable)

Key: CORE-3041
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Vlad Khorsun
Reporter: Vlad Khorsun
Votes: 0
Watchers: 0

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

Engine could hang when working with read-only database

Created: 13/Jun/10 09:04 AM   Updated: 20/Jul/15 05:27 AM
Component/s: Engine
Affects Version/s: 2.0.0, 2.0.1, 2.0.2, 2.0.3, 2.1.0, 2.0.4, 2.1.1, 2.0.5, 2.1.2, 2.1.3
Fix Version/s: 2.0.6, 2.1.4

QA Status: Cannot be tested
Test Details: No sense to check in 2.1.x. No need to test for 2.5 and above because this bug can not occur there.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Vlad Khorsun added a comment - 13/Jun/10 09:15 AM
Attachment and transactions ID's derived from values stored on header page.
In case of read-only database this values keeps in-memory and incremented as needed.
isc_database_info call leads to re-reading of header page and re-reading in-memory counterrs for next attachment and transaction IDs.
Therefore it is possible that some attachments\transactions will have the same ID's as some older attachments\transactions.
It leads to waiting of new attachment\transaction for the end of existing attachment\transaction with the same ID.
When waiting for attachment lock, global mutex is locked and old attachment can't even complete own disconnect and release attachment lock.
So, we have an endless deadlock. This is (deadlock) true for SuperServer. For Classic Server we will observe hang of some new attachment\transaction until existing attachment\transaction is alive.

v2.5 have no this bug as it derives new attachment\transaction ID from shared counter and it can't be reset by re-reading header page.

Vlad Khorsun added a comment - 13/Jun/10 09:57 AM
Hang of whole process of SuperServer is fixed.
More complete solution for CS is already implemented in v2.5

Philippe Makowski added a comment - 08/Jul/10 01:50 PM
Confimed by user