Cool, so..... On 5 March 2011 15:14, Niclas Hedhman <[email protected]> wrote:
> 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. > That's not a bad way to think about things.... > > 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. > > Again, there are a couple of orthogonal issues within this discussion: (1) Availability of service - that is what can make progress and when. e.g. You might have a setup that allows transactions created since some failure event to succeed whilst those prior don't. (2) Ultimate resolution - two phase commit has some holes that can leave a transaction unsettled forever. In essence, one must have at least one valid copy of the transaction log survive and ultimately be available at some point coinciding with a stable network state so things can sort themselves out. If you lose all copies of the log, you're toast. A transaction will hang around forever in the participants unresolved unless one introduces an additional bounding condition e.g. based on time. 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 >
