river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: [jira] Created: (RIVER-393) Distributed Java Space
Date Sat, 05 Mar 2011 15:14:32 GMT
On Sat, Mar 5, 2011 at 5:55 PM, Dan Creswell <dan.creswell@gmail.com> 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

Mime
View raw message