Uploaded image for project: 'Infinispan'
  1. Infinispan
  2. ISPN-615

Eager locking and key affinity optimisation

    Details

    • Type: Feature Request
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: 4.1.0.CR3
    • Fix Version/s: 4.2.0.ALPHA1, 4.2.0.Final
    • Component/s: None
    • Labels:
      None

      Description

      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

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                mircea.markus Mircea Markus
                Reporter:
                mircea.markus Mircea Markus
              • Votes:
                1 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: