]
Manik Surtani updated ISPN-48:
------------------------------
Fix Version/s: 4.0.0.ALPHA4
(was: 4.0.0.BETA1)
Introduce lock() and unlock() API methods
-----------------------------------------
Key: ISPN-48
URL:
https://jira.jboss.org/jira/browse/ISPN-48
Project: Infinispan
Issue Type: Feature Request
Components: Locking and Concurrency
Reporter: Manik Surtani
Assignee: Vladimir Blagojevic
Fix For: 4.0.0.ALPHA4, 4.0.0.GA
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: