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