[infinispan-dev] Introducing JGroups scopes

[Manik Surtani]

On 31 Jan 2011, at 13:55, Bela Ban wrote:

> 
> 
>> But it can get better: I propose using some mechanism to represent the lock or locks touched by the transaction as your scope.  So any other transaction touching one or more of the same locks will be serialized, everything else could happen in parallel.  Perhaps a Bloom filter?
> 
> Do you always use locks, even if there's no TX, or the locking level is 
> NONE ?

If you skip locking then things could get reordered/inconsistent even on one node.  So it is irrelevant in a distributed sense.

> If you have a TX, you could use the TX-ID as scope.

I know this is what we originally thought, but I think this might be insufficient.  Different scopes are delivered in parallel.  So tx1 and tx2 *could* be delivered in parallel, even though they touch the same keys.  E.g., they happen in sequence on node A (due to locking), but since we're talking async RPC, the 1PC prepare/commit messages could get reordered and applied on B in a different order.  And this is wrong.

Some form of understanding which keys are touched, and grouping transactions that share locks into the same scope, is what is needed.

If there are external hints, e.g., http session IDs as you suggested, this makes it much easier.

Cheers
Manik

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org