Hello all,
some team members had a meeting yesterday, one of the discussed
subjects was about using atomic operations (putIfAbsent, etc..).
Mircea just summarised it in the following proposal:
The atomic operations, as defined by the ConcurrentHashMap, don't fit
well within the scope of optimistic transaction: this is because there
is a discrepancy between the value returned by the operation and the
value and the fact that the operation is applied or not:
E.g. putIfAbsent(k, v) might return true as there's no entry for k in
the scope of the current transaction, but in fact there might be a
value committed by another transaction, hidden by the fact we're
running in repeatable read mode.
Later on, at prepare time when the same operation is applied on the
node that actually holds k, it might not succeed as another
transaction has updated k in between, but the return value of the
method was already evaluated long before this point.
In order to solve this problem, if an atomic operations happens within
the scope of a transaction, Infinispan eagerly acquires a lock on the
remote node. This locks is held for the entire duration of the
transaction, and is an expensive lock as it involves an RPC. If
keeping the lock remotely for potentially long time represents a
problem, the user can suspend the running transaction and run the
atomic operation out of transaction's scope, then resume the
transaction.
Just to make this clearer, optimistic locking is what we'll get my only acquiring locks at prepare time: