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

[Galder Zamarreño]

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

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.

2. We need an unlock()

3. Requires exclusive access, even for read operations. Our lock() implementation still allows read operations.

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).

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.

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.

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