[infinispan-dev] Extreme transactions and replication

[Mark Little]

One of the things we started to do with transactions and replication  
was build a scalable replication protocol that unified replication and  
cacheing.

http://www.cs.ncl.ac.uk/publications/inproceedings/papers/584.pdf

This works because strongly consistent replication protocols don't  
scale beyond a few replicas or over more than a LAN. That's why weak  
consistency protocols were developed back in the late 1980's. However,  
the problem with them is that they are weakly (or eventually)  
consistent and most applications can't cope with uncertainty.

Anyway, with the advent of Web Services and their need for  
transactions that span multiple companies or organizations, the notion  
of uncertainty of data becomes natural for those types of  
applications: it is simply not possible to run transactions with  
strict ACID semantics across large scale (number of participants and  
physical location). Participants need to be split into domains and  
there are typically known degrees of inconsistency between those  
domains (e.g., it takes up to an hour for all domains to become  
totally consistent assuming no further updates occur). Each  
participant in the transaction may well be a subordinate transaction  
coordinator (aka interposition) or a real business participant. If  
it's the former then within a domain there's a guarantee of  
consistency. Of course this is a hierarchical structure, so you can  
have domains within domains.

This approach has impacts on the transaction manager: failure during  
the "prepare" or "commit" protocol no longer necessarily means atomic  
outcome or assuming everything will eventually undo. But also on the  
replication protocols used (see paper). This is really what I call  
extreme transaction processing, and not what Gartner understands it to  
be. (Gartner and I have argued about this and last time we spoke I  
won ;-)

We did some of this within the OASIS WS-CAF effort, but the  
implementation needs revisiting. I've been working on and off (more  
off than on) on updating the original paper and there's been interest  
from our local university to collaborate on some R&D. I think JBossTS  
+ Infinispan would work well to solve this problem.

Mark.

---
Mark Little
mlittle at redhat.com

JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod  
Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903  
Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt  
Parsons (USA) and Brendan Lane (Ireland).