[infinispan-dev] eager locking and async replication

[Mircea Markus]

This will be tackled in 4.2:  https://jira.jboss.org/browse/ISPN-615

On 20 Aug 2010, at 12:46, Mircea Markus wrote:

> Let me detail on this a little more: the optimisation refers to cache.lock() not to perform remote locks on ALL data owners, but only on the main data owner.
> This way , if session affinity is used for enforcing key locality then cache.lock() would only acquire lock within the same JVM - i.e. very good performance without loosing eager's locking semantics. If the cluster changes, and the key is rehashed on a different node, than eager locking would do an RPC - but for many clusters the topology changes are infrequent. 
> Another problem that raises is that of consistency during node failures: if K is on node A and it was locked by a tx originated on node B. If A fails then we can invalidate the transaction on B, so that it would rollback.
> Another interesting race condition Sanne raised is with re-hashing: "it needs to be atomic to know who is the owner and aquire the lock, or the owner might be moved and you're locking on the wrong node (only)"
> I think this is not related to this optimisation in particular, but stands for eager locking in general - any idea how this is handled btw? 
> Cheers,
> Mircea
> 
> On 20 Aug 2010, at 11:04, Manik Surtani wrote:
> 
>> Not sure I understand - are you proposing that the RPC for LockControlCommands are always async if the keys are generated using the key affinity service?
>> 
>> On 19 Aug 2010, at 16:29, Mircea Markus wrote:
>> 
>>> Hi,
>>> 
>>> Here is the scenario,  N=numOwners
>>> 
>>> TM.start()
>>> c.lock(a); //this makes N (might me less) RPCs to acquire locks  
>>> c.get(a)
>>> ...
>>> TM.commit(); // this would do an N calls for prepare/commit. Might happen async.
>>> 
>>> By using the key affinity service, one might enforce a tx to operate on "local" keys (i.e. keys that are hashed on the same node where the tx was started). 
>>> Now, if we would be able to *only* eager lock the main data owner (v.s. N RPCs for lock acquisition  locks) than eager locking would be as fast as the non-eager locking for this scenario. 
>>> What happens with the TX if the data owner crashes and only one copy is locked? We would need to invalidate the transaction at originator's side, which I think is possible.
>>> For async repl with N >= 2 and key affinity the performance benefit for eager locking would be close to local puts: which is huge. 
>>> 
>>> This use case was brought by Erik ( cc)- please add you comments if something is missing. What do you think about this optimisation?
>>> 
>>> Cheers,
>>> Mircea 
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
>> --
>> Manik Surtani
>> manik at jboss.org
>> Lead, Infinispan
>> Lead, JBoss Cache
>> http://www.infinispan.org
>> http://www.jbosscache.org
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20100823/e7f63805/attachment.html