[infinispan-dev] Extreme transactions and replication

[Manik Surtani]

Hi Mark

On 10 Nov 2009, at 13:06, Mark Little wrote:

> 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 ;-)

I imagine it must have been a tough battle.  :)

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

Yes, I think so although Infinispan's distribution model is still in its infancy in that the notion of domains and subdomains with different degrees of consistency/consensus (or even replicas) isn't as yet available.  Any Infinispan grid formed is treated as a single and homogenous one with a fixed degree of consistency and number of replicas (defined declaratively at startup) but the natural progression here would be to break this into domains - we need this anyway for inter-datacentre (WAN) replication.

How specifically do you see JBossTS and Infinispan working together to solve your XTP issues though?  Using Infinispan as a shared global space to write transaction status and logs?

Cheers
--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org