[infinispan-dev] Introducing JGroups scopes

[Bela Ban]

On 1/31/11 2:33 PM, Manik Surtani wrote:
> Just to clarify, there are 2 phases to this, if you will.
>
> Phase 1: Infinispan makes use of scopes internally, for transactional and non-transactional calls to gain greater concurrency in the way JGroups broadcasts messages.
>
> Phase 2: Allow user defined scopes.
>
> Lets start with 1 and make sure we have a workable structure first.  So to revisit the problem (Vladimir/Bela - pls correct me if I am wrong), JGroups serializes the delivery of messages off the wire per-sender.


Correct


>  This means that Node A may send many messages, but a given recipient, say Node B, would queue up these messages and process them in order.  This means that even though we may have many threads on A doing non-related work, on disjoint data sets, and although this happens in parallel on A, by the time they get to B they get processed in order


Yes


> To work around this, we use the OOB flag for synchronous messages (since we hold locks for these until the RPC returns and we know that data from such transactions cannot get reordered leading to inconsistent data).
>
> The issue is that if we use _async_ mode, we cannot use OOB since things can get reordered and hence inconsistent, and we _rely_ on JGroups processing messages in order to maintain consistency.


Yes

> Scopes helps us parallelize this.  On a very basic level, if the scope is a cache name, then at least transactions on different caches in the same cache manager can be handled in parallel.

Correct


>  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 have a TX, you could use the TX-ID as scope.

-- 
Bela Ban
Lead JGroups / Clustering Team
JBoss