[infinispan-issues] [JBoss JIRA] Updated: (ISPN-615) Eager locking and key affinity optimisation

[Mircea Markus (JIRA)]

     [ https://jira.jboss.org/browse/ISPN-615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mircea Markus updated ISPN-615:
-------------------------------

    Fix Version/s: 4.2.0.ALPHA1
                       (was: 4.2.0.ALPHA2)


> Eager locking and key affinity optimisation
> -------------------------------------------
>
>                 Key: ISPN-615
>                 URL: https://jira.jboss.org/browse/ISPN-615
>             Project: Infinispan
>          Issue Type: Feature Request
>    Affects Versions: 4.1.0.CR3
>            Reporter: Mircea Markus
>            Assignee: Mircea Markus
>             Fix For: 4.2.0.ALPHA1, 4.2.0.Final
>
>
> 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, then eager locking would do a RPC - but for many clusters the topology changes are infrequent. 
> 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 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira