<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 6, 2013 at 7:48 PM, Galder Zamarreņo <span dir="ltr"><<a href="mailto:galder@redhat.com" target="_blank">galder@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
We're meant to implement this method in JSR-107:<br>
<a href="https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cache/Cache.java#L510" target="_blank">https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cache/Cache.java#L510</a><br>
<br>
The interesting bit comes in the javadoc of EntryProcessor: <a href="https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cache/Cache.java#L510" target="_blank">https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cache/Cache.java#L510</a><br>
<br></blockquote><div><br></div><div>The EntryProcessor javadoc link is wrong, it should be <a href="https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cache/Cache.java#L618">https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cache/Cache.java#L618</a> :)<br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
To be more precise:<br>
<br>
" * Allows execution of code which may mutate a cache entry with exclusive<br>
* access (including reads) to that entry.<br>
* <p/><br>
* Any mutations will not take effect till after the processor has completed; if an exception<br>
* thrown inside the processor, the exception will be returned wrapped in an<br>
* ExecutionException. No changes will be made to the cache.<br>
* <p/><br>
* This enables a way to perform compound operations without transactions<br>
* involving a cache entry atomically. Such operations may include mutations."<br>
<br>
Having quickly glanced, there's several things that need addressing from Infinispan internals perspective:<br>
<br>
1. Implies that we need to be able to lock a key without a transaction, something we don't currently support.<br>
<br></blockquote><div><br></div><div>Actually we don't support it with optimistic transactions either (see OptimisticLockingInterceptor#visitLockControlCommand()).<br></div><div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2. We need an unlock()<br>
<br></blockquote><div><br></div><div>Even if we do implement it, I wouldn't allow user code to call lock/unlock in non-transactional caches.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
3. Requires exclusive access, even for read operations. Our lock() implementation still allows read operations.<br>
<br></blockquote><div><br></div><div>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? <br><br></div><div>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.<br>
</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
These are fairly substantial changes (I'm planning to add them as subtasks to <a href="https://issues.jboss.org/browse/ISPN-2639" target="_blank">https://issues.jboss.org/browse/ISPN-2639</a>) particularly 1) and 3), and so wanted to share some thoughts:<br>
<br>
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).<br>
<br></blockquote><div><br></div><div>Shouldn't this work with any cache configuration? If yes, then every LockingInterceptor implementation should handle it.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.<br>
<br></blockquote><div><br></div><div>Again, I think this should be a new command (or a new flag on LockControlCommand) and every LockingInterceptor implementation should handle it.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.<br>
<br></blockquote><div><br></div><div>Except it won't always be NonTransactionalLockingInterceptor...<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Before I get started with this, I wanted to get the thoughts/opinions of the list.<br>
<br>
Cheers,<br>
--<br>
Galder Zamarreņo<br>
<a href="mailto:galder@redhat.com">galder@redhat.com</a><br>
<a href="http://twitter.com/galderz" target="_blank">twitter.com/galderz</a><br>
<br>
Project Lead, Escalante<br>
<a href="http://escalante.io" target="_blank">http://escalante.io</a><br>
<br>
Engineer, Infinispan<br>
<a href="http://infinispan.org" target="_blank">http://infinispan.org</a><br>
<br>
<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</blockquote></div><br></div></div>