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

Support concurrent updates for non-transactional caches

This issue belongs to an archived project. You can view it, but you can't modify it. Learn more

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Done
    • Icon: Blocker Blocker
    • 5.2.0.Final
    • 5.1.0.FINAL
    • None
    • None

      for non-transactional caches, when a key is updated, a local lock is acquired and also a lock on all the owning nodes as well. This is very inefficient for concurrent updates as it is very deadlock-prone.
      The following locking approach should solve this problem at the cost of an additional RPC:

      • 'k' is written on node A, owners(k)= {B,C}
      • A forwards the given command to B
      • B acquires a lock on 'k' then it forwards it to the remaining owners: C
      • C applies the change and returns to B (no lock acquisition is needed)
      • B applies the result as well, releases the lock and returns the result of the operation to A.

      Note that even though this introduces an additional RPC (the forwarding), it behaves very well in conjunction with consistent-hash aware hotrod clients which connect directly to the lock owner.

              mircea.markus Mircea Markus (Inactive)
              mircea.markus Mircea Markus (Inactive)
              Archiver:
              rhn-support-adongare Amol Dongare

                Created:
                Updated:
                Resolved:
                Archived: