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

Non-transactional INVALIDATION_SYNC cache deadlock

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

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 12.0.0.Final
    • 10.1.8.Final, 11.0.5.Final, 12.0.0.Final
    • Core
    • None
    • DataGrid Sprint #53
    • Hide

      Possible workarounds:

      • Use a transactional invalidation cache. Tx caches use the same locking scheme as replicated caches since ISPN-10029, but need more RPCs so are slower.
      • Use asynchronous replication (cache mode INVALIDATION_ASYNC).

      Because in this case the invalidation cache uses a RemoteStore backed by a HotRod cluster, it would also be possible to use a HotRod client with near-cache enabled. Performance characteristics are obviously very different since invalidations arrive from the servers, but ISPN-10216 will improve that a lot.

      Show
      Possible workarounds: Use a transactional invalidation cache. Tx caches use the same locking scheme as replicated caches since ISPN-10029 , but need more RPCs so are slower. Use asynchronous replication (cache mode INVALIDATION_ASYNC). Because in this case the invalidation cache uses a RemoteStore backed by a HotRod cluster, it would also be possible to use a HotRod client with near-cache enabled. Performance characteristics are obviously very different since invalidations arrive from the servers, but ISPN-10216 will improve that a lot.
    • Undefined

      Non-transactional invalidation caches use the old locking scheme from Infinispan 4.x, which is prone to deadlocks:

      1. put(k, v1) is invoked on node A and acquires lock k
      2. put(k, v2) is invoked on node B and acquires lock k
      3. A sends an InvalidateCommand(k) RPC to B
      4. B sends an InvalidateCommand(k) RPC to A
      5. The InvalidateCommand(k) from A and tries to acquire lock k on B
      6. The InvalidateCommand(k) from B and tries to acquire lock k on A
      7. Both InvalidateCommand(k) lock acquisitions eventually time out and release lock k on their originators.

              dberinde@redhat.com Dan Berindei (Inactive)
              dberinde@redhat.com Dan Berindei (Inactive)
              Archiver:
              rhn-support-adongare Amol Dongare

                Created:
                Updated:
                Resolved:
                Archived: