Re: [infinispan-dev] Introducing JGroups scopes
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(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org