river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <dan.cresw...@gmail.com>
Subject Re: [jira] Created: (RIVER-393) Distributed Java Space
Date Sat, 05 Mar 2011 20:04:11 GMT
Cool, so.....

On 5 March 2011 15:14, Niclas Hedhman <niclas@hedhman.org> wrote:

> 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.
>

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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message