Niclas Hedhman wrote: > It is quite interesting to compare the Jini Transaction specification > [1] with JTA, and my gut is feeling so much better with the former. > > Since "participants" (that is those that have state to be modified) in > Jini Transactions are generally more "identifiable" than vague > services in the JTA sphere, I find one thing with Jini Transactions > particularly interesting; > > <quote> > If a participant votes PREPARED for a top-level transaction, it must > guarantee that it will execute a recovery process if it crashes > between completing its durable record and receiving a commit > notification from the manager. > </quote> > > i.e. crash recovery is an integral view of the whole spec. At a > successful prepare(), the participant makes a commitment to the > Txmanager that it will indeed manage to perform a commit() if asked to > do so, no matter what happens from now until then. The specification > also notes that a permanent failure of the participant to re-join the > transaction puts the entire state in jeopardy. > > > I have not seen such in-depth analysis of JTA/JTS cause/effect and > potential problems as this one.
Considering this, how do you feel that our EntityStore.prepare/StateCommitter works? Is it good enough, or should we specify more of the behaviour, in line with Jini Tx thinking? /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
