Fix transaction support in Mulgara to support concurrent reads and read-only transactions. - Currently ACID failure
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.
Updated by Andrae Muys - about 16 years ago
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.