[infinispan-dev] Extreme transactions and replication

[Mark Little]

I forgot to include a few slides from a presentation I gave last year.

Mark.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Winter School 2008.pdf
Type: application/pdf
Size: 178929 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20091110/1db3aaa2/attachment-0002.pdf 
-------------- next part --------------

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 ;-)
>
> 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).
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

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