On 3/5/2011 7:14 AM, Niclas Hedhman 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.
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.
Patricia
