On Wed, Feb 6, 2013 at 7:48 PM, Galder Zamarreño <galder(a)redhat.com&gt; wrote: Hi all, We're meant to implement this method in JSR-107: https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cach... The interesting bit comes in the javadoc of EntryProcessor: https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cach... The EntryProcessor javadoc link is wrong, it should be https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cach... :) To be more precise: " * Allows execution of code which may mutate a cache entry with exclusive * access (including reads) to that entry. * <p/> * Any mutations will not take effect till after the processor has completed; if an exception * thrown inside the processor, the exception will be returned wrapped in an * ExecutionException. No changes will be made to the cache. * <p/> * This enables a way to perform compound operations without transactions * involving a cache entry atomically. Such operations may include mutations." Having quickly glanced, there's several things that need addressing from Infinispan internals perspective: 1. Implies that we need to be able to lock a key without a transaction, something we don't currently support. Actually we don't support it with optimistic transactions either (see OptimisticLockingInterceptor#visitLockControlCommand()). 2. We need an unlock() Even if we do implement it, I wouldn't allow user code to call lock/unlock in non-transactional caches. 3. Requires exclusive access, even for read operations. Our lock() implementation still allows read operations. What happens on other nodes? Do we have to block threads on other nodes that want to read the entry from their own L1 cache? I think the intention of this requirement is not really to block readers from executing, but from seeing incomplete values. So we should be complying with the spirit (if not the letter) of the specification if we made a copy of the entry before handing it over to the EntryProcessor. These are fairly substantial changes (I'm planning to add them as subtasks to https://issues.jboss.org/browse/ISPN-2639) particularly 1) and 3), and so wanted to share some thoughts: For 1 and 2, the easiest way I can think of doing this is by having a new LockingInterceptor that is similar to NonTransactionalLockingInterceptor, but unlocks only when unlock is called (as opposed to after each operation finishes). Shouldn't this work with any cache configuration? If yes, then every LockingInterceptor implementation should handle it. For 3, we'd either need to add a new lock() method that supports locking read+write, or change lock() behaivour to also lock reads. The latter could break old clients, so I'd go for a new lock method, i.e. lockExclusively(). Again, to support this, a new different NonTransactionalLockingInterceptor is needed so that locks are acquired on read operations as well. Again, I think this should be a new command (or a new flag on LockControlCommand) and every LockingInterceptor implementation should handle it. Finally, any new configurations could be avoided at this stage by simply having the JSR-107 adapter inject the right locking interceptor. IOW, if you use JSR-107, we'll swap NonTransactionalLockingInterceptor for JSR107FriendlyNonTransactionalLockingInterceptor. Except it won't always be NonTransactionalLockingInterceptor... Before I get started with this, I wanted to get the thoughts/opinions of the list. Cheers, -- Galder Zamarreño galder(a)redhat.com twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev