Bug #19
Fix transaction support in Mulgara to support concurrent reads and read-only transactions. - Currently ACID failure
Added by Andrae Muys - over 17 years ago.
Updated over 17 years ago.
Description
A correct implementation of server-side JRDF requires support for concurrent reads.
<br/>
<br/>
Any client side round-tripping of blank-nodes requires access to read-only transactions.
<br/>
<br/>
This requires refactoring (and some rewriting of) transaction support in the Session layer of Mulgara to support three-level transaction representation.
<br/>
<br/>
User - We require a seperate transaction object representing a users transaction. Currently represented by a javax.transaction.Transaction object on [[DatabaseSession]]. This needs encapsulating.
<br/>
Query - We don't currently have any concept of a transaction at the per-query level. Without this concurrent reads can't be supported.
<br/>
Method - Currently supported via methods on [[DatabaseSession]]. These need to be lifted into a seperate manager object which can manage their interaction with query and user transactional contexts.
Violation of ACID Isolation in endPreviousQueryTransaction
<br/>
<br/>
Failure to close [[SubqueryAnswer]] object in
<br/>
[[DatabaseSession]].endPreviousQueryTransaction() results in a
<br/>
violation of ACID isolation for subqueries and counts when issuing
<br/>
new queries if the Answers from previous queries have not been
<br/>
closed.
<br/>
<br/>
The offending code is currently on line 868 of [[DatabaseSession]].java:
<br/>
<br/>
//Do not close tuples - for Jena and JRDF.
<br/>
//s.close();
<br/>
<br/>
NOTE: ACID is restored by uncommenting s.close(); however server-side JRDF is then broken. This is exposed by the following sequence:
<br/>
<br/>
Violation of ACID Isolation in [[DatabaseSession]].innerQuery
<br/>
<br/>
[[DatabaseSession]].innerQuery() fails to invalidate all Answer objects
<br/>
associated with a given transaction when the transaction ends. This
<br/>
is a violation of ACID isolation under the following use case:
<br/>
<br/>
1) Set autocommit off;
<br/>
2) perform a query with a subquery;
<br/>
3) write something into the store which would change the results of
<br/>
the query in (2);
<br/>
4) Get the subquery results from the Answer object from (2).
<br/>
<br/>
The subquery will not be isolated from the write.
This issue subsumes the concurrent write problem described in:
<br/>
<a href="http://mulgara.org/trac/ticket/2">http://mulgara.org/trac/ticket/2</a>
Moved to "Blocker" priority
Fixed in revision <a href="http://mulgara.org/trac/changeset/138">138</a> in the branches/xafix-impl branch.
<br/>
<br/>
Please test.
Also available in: Atom
PDF