hi reto, thanks for initiating this discussion. I am also unfamiliar with java transaction. so it is necessary to get familiar with this first. or if someone else could sketch it here in brief, that might help.
I have the following questions (just to understand your thoughts): 1. read and write operations shall only be performed through transaction object (returned by tm.createTransaction), right? 2. If transactions are in used, should we prevent direct access to mgraphs? 3. what is the role of tcmanager if direct access to mgraphs are not allowed. 4. further, any good reason to pass singleton TcManager to createTransaction? regards hasan On Mon, Sep 27, 2010 at 9:56 AM, Reto Bachmann-Gmuer <[email protected]>wrote: > *Wishlist* > > - CLEREZZA-219: Rollback / atomicity > - A committed Transactions is like a patch to a set of graphs > - Transaction can be copied and executed on another instance > - Optimistic concurrency control > - Code that doesn't modifies MGraphs need no transactions > - No more ConurrentModificationException: Iterators returned by MGraphs > point to the version at the moment of invocation > > *Problems* > > - Consistency with Bnode > - Suppose we have an mGraph with: _:a rdf:type ex:Animal > - The transactions t1 and t2 both read the above unique triple of the > MGraph > - t1 adds _:a rdf:type ex:Cat > - t2 adds _:a rdf:type ex:Dog > - The second thread should fail to commit > > *Solution approach* > > I'm unfamiliar with the java transaction api, I'm not sure how this could > replace/affect the following > > I immagine the api being used like this (in Scala, in Java some additional > interfaces would be needed) > > val tm: TcTransasctionManager = ... > val t = tm.createTransaction { tcManager => > val mGraph = tcManger.getMGraph(new UriRef("http://example.org/test.graph > ")) > //within this block it appears as if there's no one else in the world, we > don't have to care > //about locking > } > //retries up to 5 time if applying the result patch fails > //transactions that perform only read operations produce an empty patch and > commit thus never fails > val result = t.commit(5) > > //we could also run the transaction without any change being actualy sone > to > the tcManager > //val result = t.simulate() > > A Transaction is specified by a function that takes a TcManager, the > functionality of the transaction is implemented in this function and all > access to mGraphs occurs via the the TcManager received as argument. The > list of triple collections as well as the triple collection returned by > this > TcManager appear not to change unless for the changes done within the > perform method. > > - when a transaction is committed or when a read access is done, all > previous write call are transformed into a patch, this patch is > associated > to the transaction > - All read access are performed against a base graph and a set of > transaction that have been committed but have not yet been applied to the > base graph or that are associated to the transaction performing the read > operation. > - Changes within a transaction produce a patch, at the time of commit it > is checked that the mgraph is still compatible with the change (removed > triples are still there and the context of affected bnodes is unchanged) > - when a triple is added or removed containing an existing bnode (one > that has not been added with the transaction) a the context of this bnode > in > the original graph is marked for removal and a replacement subgraph with > distinct bnode objects is created. > - A scheduled task monitors the readlock on mGraphs and choosed suitable > moments for applying committed patches to the base mgraph, only during > this > operation the base mgraph is write-locked. No transaction function is > executed while patches are applied, no iterator should be open the mGraph > or > some mechanism not to ConcurrentModificationExceptions must be applied. > > > *Performance* > On read access apart from the base-graph a set of patches has to be > checked, > both for additions and removals of triples. As under normal circumstances > the umber of patches should be relatively small this shouldn't be too bad. > Write operations should get significantly faster as generating and adding a > patch does not require a qrite lock on the base graph. >
