Loading...

XML

Word

Printable

Sprint:
DataGrid Sprint #53
Forum Reference:
https://infinispan.zulipchat.com/#narrow/stream/118645-infinispan/topic/PutOperation.20timeout.20due.20to.20lock
Workaround Description:
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.
Release Note Text:
Undefined
Git Pull Request:
https://github.com/infinispan/infinispan/pull/8848

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

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