-
Bug
-
Resolution: Done
-
Major
-
None
-
None
putForExternalRead behaves as an asynchronous, non-transactional write operation even in tx caches, and as such it uses lock delegation.
Let's say we have a cluster with two nodes: [A, B], and a key k with owners(k) = [A, B].
If B is the originator of a PFER(k, v) operation, the command is first executed locally on B, then it is invoked asynchronously on the primary owner A, and A invokes it asynchronously on B (because of the FORCE_ASNCHRONOUS flag).
For regular non-tx write operations, the entry k=v is only written to the data container on B during the second invocation. For PFER, however, the entry is written twice: once during each execution.
This causes random failures in PutForExternalRead*Test.testNoOpWhenKeyPresent, because the test assumes that the PFER finished once the entry was written once on each owner.
Arguably the fact that the primary owner forwards the PFER command asynchronously is also a problem, because the put command will write the value on B without holding a lock on A, the primary owner.
- relates to
-
ISPN-3639 Local PutForExternalRead failing to apply locally in invalidated caches
- Closed