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 _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
