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: Manik Surtani Fix For: 4.2.0.BETA1, 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