[infinispan-dev] Adding JSR-107 support for invokeEntryProcessor

[Dan Berindei]

On Wed, Feb 6, 2013 at 7:48 PM, Galder Zamarreño <galder at redhat.com> 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
> galder at redhat.com
> twitter.com/galderz
>
> Project Lead, Escalante
> http://escalante.io
>
> Engineer, Infinispan
> http://infinispan.org
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130207/7be7da45/attachment.html