I think this might best be implemented as a specific command... On 7 Feb 2013, at 14:06, Dan Berindei <[email protected]> wrote:
> > > > On Wed, Feb 6, 2013 at 7:48 PM, Galder Zamarreño <[email protected]> wrote: > Hi all, > > We're meant to implement this method in JSR-107: > https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cache/Cache.java#L510 > > The interesting bit comes in the javadoc of EntryProcessor: > https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cache/Cache.java#L510 > > > The EntryProcessor javadoc link is wrong, it should be > https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cache/Cache.java#L618 > :) > > 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 > [email protected] > twitter.com/galderz > > Project Lead, Escalante > http://escalante.io > > Engineer, Infinispan > http://infinispan.org > > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani [email protected] twitter.com/maniksurtani Platform Architect, JBoss Data Grid http://red.ht/data-grid
_______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
