river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <p...@acm.org>
Subject Re: [jira] Created: (RIVER-393) Distributed Java Space
Date Sat, 05 Mar 2011 15:37:50 GMT
On 3/5/2011 7:14 AM, Niclas Hedhman 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.

This is a very helpful indication of the real world requirements.

> 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 have a vague memory of seeing a research paper on distributed 
transaction management in the last year or so. I intend to do a library 
search to make sure we have access to the latest ideas from the academic 
world. If this is an area of active research we may even be able to 
co-opt a researcher who would like to see their ideas turned into a real 
world implementation.

I'm actually inclined to tackle distributed, resilient transaction 
management first, for two reasons:

1. I'm dubious about whether a distributed JavaSpace would really be 
useful without it.

2. I think it may be useful in maintaining consistency among duplicated 
copies of the same entry.


View raw message