Open tzaeschke opened 1 year ago
The "hang" has only been fixed when setting DiskAccessOneFile.allowReadConcurrency(true);
, however this is generally not recommended (and not an official feature!).
Fixing the hang properly requires an improved locking mechanism, e.g.
A call to
commit()
after defining a new database schema may hang indefinitely after if another transaction is open (in the same PMF).and
Analysis
Workaround:
Define the schema before opening other transactions.
Background
This happens because the second transaction is (implicitly) creating a schema for Apple in the database. Multithreading should work fine in normal use cases, but schema definition is different. In effect, a schema definition causes all PMF session to reset, however the reset is blocked because the first PM (pmMain) is still active.
Fix?
Causing all transactions to reset after schema change is a kind of pessimistic fail-early approach. Alternatively, Transaction reset could be delayed until a transaction actually tries to read or write to an outdated schema, I am not sure whether that would necessarily be better. It may also impact performance.
TODO
Either the problem should be fixed (=no blocking behavior), or there should be at least a proper error message what is happening.
Another user reported that making the lock reentrant fixes the problem. This is not the preferred solution because the server is designed such that reentrant locks should not be necessary. In the server design, entering a lock twice points to a problem in the server that should be fixed.