This would be the fabled distributed locking.
These APIs should be on AdvancedCache, with the following sigs:
void lock(K key, boolean eager);
void lock(Collection<? extends K> keys, boolean eager);
void unlock(K key);
void unlock(Collection<? extends K> keys);
The implementation should use a new Command, a LockControlCommand, which contains:
- a boolean to indicate whether this is a lock or unlock
- a boolean to indicate whether this is an eager lock
- an array of keys to be locked/unlocked
The command is handled by the LockingInterceptor which will acquire/release locks as needed.
If eager, the ReplicationInterceptor will replicate this command synchronously (even if repl mode is async) to ensure all remote nodes have locked/unlocked as well. (should this sync force only be on lock() and not unlock()?) If using DIST, this would only be replicated among peers where the relevant keys are mapped.
On a transaction prepare, lock()s that are NOT eager should also be respected and applied.
On transaction rollback, locks should be unlocked as usual, so unlock() commands need not be a part of the prepare.
ISPN-70 Transparent eager locking for transactions