On Sat, Mar 5, 2011 at 5:55 PM, Dan Creswell <[email protected]> wrote: > Transactions don't actually matter in any of the above as they are just > another form of operation boundary. Transactions are "durable": > > "The results of a transaction should be as persistent as the entity on which > the transaction commits." > > But that's ultimately defined by (3) above, rather than transactions > themselves.
After recently spent a lot of evaluation on 'persisted spaces', I can only say 2 things; - It is hard to get right with the SLA that matters; - The SLA that I, the enterprise developer of resilient HA system, care about is that once the operation completes (call it transaction commit), the state transition is preserved even if N arbitrary failures occur, AND that the system has a computable T time to restore itself from 'reduced HA' to 'full HA' within which additional failures beyond N is not guaranteeing preservation of state transition. The larger the T, the more N I need which increases my cost profile. The are of the Jini Transaction Specification is really interesting, since one needs to figure out how to make the transaction manager distributed and resilient as well, and recovery from a transaction manager failure, half way through second phase... I don't even want to imagine it. You might find that a new, less featureful spec is the best recourse. I am really curious of what will come out of this discussion. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/3xugrbk I work here; http://tinyurl.com/24svnvk I relax here; http://tinyurl.com/2cgsug
