Ticket #19 (closed defect: fixed)

Opened 2 years ago

Last modified 2 years ago

Fix transaction support in Mulgara to support concurrent reads and read-only transactions. - Currently ACID failure

Reported by: andrae Assigned to: andrae
Priority: blocker Milestone:
Component: Mulgara Version: 1.0.0
Keywords: Cc:

Description

A correct implementation of server-side JRDF requires support for concurrent reads.

Any client side round-tripping of blank-nodes requires access to read-only transactions.

This requires refactoring (and some rewriting of) transaction support in the Session layer of Mulgara to support three-level transaction representation.

User - We require a seperate transaction object representing a users transaction. Currently represented by a javax.transaction.Transaction object on DatabaseSession. This needs encapsulating.
Query - We don't currently have any concept of a transaction at the per-query level. Without this concurrent reads can't be supported.
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.

Change History

09/16/06 10:03:06 changed by andrae

Violation of ACID Isolation in endPreviousQueryTransaction

Failure to close SubqueryAnswer object in
DatabaseSession.endPreviousQueryTransaction() results in a
violation of ACID isolation for subqueries and counts when issuing
new queries if the Answers from previous queries have not been
closed.

The offending code is currently on line 868 of DatabaseSession.java:

//Do not close tuples - for Jena and JRDF.
//s.close();

NOTE: ACID is restored by uncommenting s.close(); however server-side JRDF is then broken. This is exposed by the following sequence:

Violation of ACID Isolation in DatabaseSession.innerQuery

DatabaseSession.innerQuery() fails to invalidate all Answer objects
associated with a given transaction when the transaction ends. This
is a violation of ACID isolation under the following use case:

1) Set autocommit off;
2) perform a query with a subquery;
3) write something into the store which would change the results of
the query in (2);
4) Get the subquery results from the Answer object from (2).

The subquery will not be isolated from the write.

10/01/06 08:09:44 changed by pag

This issue subsumes the concurrent write problem described in:
http://mulgara.org/trac/ticket/2

10/01/06 08:14:43 changed by pag

Moved to "Blocker" priority

11/22/06 22:49:08 changed by andrae

Fixed in revision 138 in the branches/xafix-impl branch.

Please test.