Project

General

Profile

Feature #37

Lock-splitting required for MulgaraTransactionManager

Added by Andrae Muys - over 17 years ago. Updated over 16 years ago.

Status:
Closed
Priority:
High
Assignee:
Category:
Mulgara
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:
fixed

Description

While documenting the new transaction work I noticed that the read-only and read-write paths through the Manager share the came lock - the manager just uses synchronized methods (ie. is a monitor).
<br/>

<br/>
As read-write transactions can block for a substantial duration during a commit, while the block-cache is flushed to disk, they should not hold the same lock as the read-only methods require to initate read-transactions while this is happening.
<br/>

<br/>
The solution is to introduce two locks independent of the manager's monitor lock.
<br/>

<br/>
1. Covering alterations to the transaction metadata held in the manager, all of which are simple O(1) operations.
<br/>
2. Covering alterations to the write-lock/writing-session metadata, which must be held over a commit().
<br/>

<br/>
Deadlock is not possible as the 2nd lock is only obtained by sessions wishing to obtain the writelock.
<br/>

Also available in: Atom PDF