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(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev