<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Mar 28, 2017 at 11:24 AM Sanne Grinovero <<a href="mailto:sanne@infinispan.org">sanne@infinispan.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Will,<br class="gmail_msg">
<br class="gmail_msg">
I'm confused about the premise; when you state<br class="gmail_msg">
<br class="gmail_msg">
" the Consumer is called while holding the lock for the given key and<br class="gmail_msg">
subsequently released after the Consumer operation completes."<br class="gmail_msg">
<br class="gmail_msg">
What are the transaction boundaries?<br class="gmail_msg">
I see two options, please correct me so I understand:<br class="gmail_msg">
<br class="gmail_msg">
A)<br class="gmail_msg">
<br class="gmail_msg">
transaction.begin();<br class="gmail_msg">
cache.lockedStream().filterKeys(keys).filter(predicate).forEach(<br class="gmail_msg">
someOperation );<br class="gmail_msg">
transaction.commit(); <-- release all locks<br class="gmail_msg">
<br class="gmail_msg">
B)<br class="gmail_msg">
<br class="gmail_msg">
cache.lockedStream().filterKeys(keys).filter(predicate).forEach(<br class="gmail_msg">
transaction.begin();<br class="gmail_msg">
//to stuff on entry<br class="gmail_msg">
/transaction.commit(); <-- release this single entry's lock<br class="gmail_msg">
);<br class="gmail_msg"></blockquote><div><br></div><div>The user code doesn't really affect this, it is done internally by Infinispan. We would acquire the lock on the user's behalf in the stream operation then call the user's accept method. Then after they return we would unlock the lock. The way I have it implemented at the moment in my PoC (which could change) is I don't even start a transaction. It just locks the key and then if the user were to invoke an operation that requires a transaction it adds the lock owner to their tx context at that point so they have ownership of the key.</div><div><br></div><div>Also to note that a commit or rollback in the Consumer currently doesn't release the lock on the key. Although this could be discussed to be possibly changed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
<br class="gmail_msg">
I think it's important to clarify this as I suspect that #A is not<br class="gmail_msg">
implementable within reasonable guarantees, while in the case of B# I<br class="gmail_msg">
see no use for optimistic locking *from a user's perspective*.<br class="gmail_msg"></blockquote><div><br></div><div>Exactly my thoughts regarding optimistic. I don't think #A is even feasible given constraints of having a distributed transaction like this.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
Also: what kind of guarantees do you expect about having the operation<br class="gmail_msg">
being applied on some entry which is strictly *still* a subset of the<br class="gmail_msg">
keys as defined by the filter predicates?<br class="gmail_msg">
I take it you'd want to acquire the locks during the filtering process?<br class="gmail_msg"></blockquote><div><br></div><div>That is a good question. I hadn't thought about the details but what I had implemented was we have to first read the entry, lock the key, reread the entry (in case of concurrent update) and then finally call their Predicate. Another reason the filterKeys is much more efficient :) Note this read, locking and reread is done even without a Predicate supplied. And actually I can also optimize filterKeys to not do the initial read since we already have the key.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
That would require the move the transaction boundary to the scenario<br class="gmail_msg">
A# which seems undesirable.<br class="gmail_msg">
Technically if I were to need something like this I guess I'd expect<br class="gmail_msg">
to have a user experience akin to B# but have Infinispan essentially<br class="gmail_msg">
use optimistic locking (and auto-skip) on entries which are mutated<br class="gmail_msg">
and fall out of the filter predicate during the lock attempt.<br class="gmail_msg">
<br class="gmail_msg">
Essentially I suspect that we'd not want to implement different<br class="gmail_msg">
versions of this depending on the transaction mode, but figure out the<br class="gmail_msg">
use case and implement a one and only transaction mode which suites<br class="gmail_msg">
such use cases. So for example we'd simply not offer a mode which<br class="gmail_msg">
requires to copy the whole grid into the current TX context.<br class="gmail_msg"></blockquote><div><br></div><div>This was never the intent and in my follow up emails I came to what seems like the same conclusion that basically this can't be done with the user controlling the transaction and it doesn't really make sense in an optimistic transaction (since you are already at that node, you are already doing everything pessimistically).</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
Thanks,<br class="gmail_msg">
Sanne<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
On 28 March 2017 at 14:49, William Burns <<a href="mailto:mudokonman@gmail.com" class="gmail_msg" target="_blank">mudokonman@gmail.com</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> On Mon, Mar 27, 2017 at 9:02 PM Galder Zamarreño <<a href="mailto:galder@redhat.com" class="gmail_msg" target="_blank">galder@redhat.com</a>> wrote:<br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>> --<br class="gmail_msg">
>> Galder Zamarreño<br class="gmail_msg">
>> Infinispan, Red Hat<br class="gmail_msg">
>><br class="gmail_msg">
>> > On 21 Mar 2017, at 17:16, Dan Berindei <<a href="mailto:dan.berindei@gmail.com" class="gmail_msg" target="_blank">dan.berindei@gmail.com</a>> wrote:<br class="gmail_msg">
>> ><br class="gmail_msg">
>> > I'm leaning towards option 1.<br class="gmail_msg">
>> ><br class="gmail_msg">
>> > Are you thinking about also allowing the consumer to modify the entry,<br class="gmail_msg">
>> > like JCache's EntryProcessors? For a consumer that can only modify the<br class="gmail_msg">
>> > current entry, we could even "emulate" locking in an optimistic cache<br class="gmail_msg">
>> > by catching the WriteSkewException and running the consumer again.<br class="gmail_msg">
>> ><br class="gmail_msg">
>> > I wouldn't allow this to be mixed with other operations in a stream,<br class="gmail_msg">
>> > because then you may have to run filters/mappers/sorting while holding<br class="gmail_msg">
>> > the lock as well.<br class="gmail_msg">
>><br class="gmail_msg">
>> ^ Would forEach w/ lock still run for all entries in originator? If so,<br class="gmail_msg">
>> not being able to filter could be a pain. IOW, you'd be forcing all entries<br class="gmail_msg">
>> to be shipped to a node and user to do its own filtering. Not ideal :\<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> No the primary owner would run the operation per entry. I was thinking we<br class="gmail_msg">
> would have 2 levels of filtering in my proposal above.<br class="gmail_msg">
><br class="gmail_msg">
> We would have the first one which is using filterKeys on the CacheStream<br class="gmail_msg">
> method. This requires serializing keys sent to each node (only primary owned<br class="gmail_msg">
> keys are sent). While it has the cost of serialization it makes up for by<br class="gmail_msg">
> having constant time lookups (no iterating memory/stores) for the keys as it<br class="gmail_msg">
> creates a stream using Cache.get to populate it.<br class="gmail_msg">
><br class="gmail_msg">
> The second was to support the filter method on the Stream API which would<br class="gmail_msg">
> allow for a Predicate so you don't have to serialize keys. In this case you<br class="gmail_msg">
> wouldn't want to include keys in this Predicate as all keys would be<br class="gmail_msg">
> serialized to all nodes and then you still have to iterate and check the<br class="gmail_msg">
> entire data container/store.<br class="gmail_msg">
><br class="gmail_msg">
> You could actually do both as well. So if you only want a subset of known<br class="gmail_msg">
> keys where their values match a Predicate this can be done too.<br class="gmail_msg">
><br class="gmail_msg">
> cache.lockedStream().filterKeys(keys).filter(predicate).forEach();<br class="gmail_msg">
><br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>> ><br class="gmail_msg">
>> > Cheers<br class="gmail_msg">
>> > Dan<br class="gmail_msg">
>> ><br class="gmail_msg">
>> ><br class="gmail_msg">
>> > On Tue, Mar 21, 2017 at 5:37 PM, William Burns <<a href="mailto:mudokonman@gmail.com" class="gmail_msg" target="_blank">mudokonman@gmail.com</a>><br class="gmail_msg">
>> > wrote:<br class="gmail_msg">
>> >> Some users have expressed the need to have some sort of forEach<br class="gmail_msg">
>> >> operation<br class="gmail_msg">
>> >> that is performed where the Consumer is called while holding the lock<br class="gmail_msg">
>> >> for<br class="gmail_msg">
>> >> the given key and subsequently released after the Consumer operation<br class="gmail_msg">
>> >> completes.<br class="gmail_msg">
>> >><br class="gmail_msg">
>> >> Due to the nature of how streams work with retries and performing the<br class="gmail_msg">
>> >> operation on the primary owner, this works out quite well with forEach<br class="gmail_msg">
>> >> to be<br class="gmail_msg">
>> >> done in an efficient way.<br class="gmail_msg">
>> >><br class="gmail_msg">
>> >> The problem is that this only really works well with non tx and<br class="gmail_msg">
>> >> pessimistic<br class="gmail_msg">
>> >> tx. This obviously leaves out optimistic tx, which at first I was a<br class="gmail_msg">
>> >> little<br class="gmail_msg">
>> >> worried about. But after thinking about it more, this prelocking and<br class="gmail_msg">
>> >> optimistic tx don't really fit that well together anyways. So I am<br class="gmail_msg">
>> >> thinking<br class="gmail_msg">
>> >> whenever this operation is performed it would throw an exception not<br class="gmail_msg">
>> >> letting<br class="gmail_msg">
>> >> the user use this feature in optimistic transactions.<br class="gmail_msg">
>> >><br class="gmail_msg">
>> >> Another question is what does the API for this look like. I was<br class="gmail_msg">
>> >> debating<br class="gmail_msg">
>> >> between 3 options myself:<br class="gmail_msg">
>> >><br class="gmail_msg">
>> >> 1. AdvancedCache.forEachWithLock(BiConsumer<Cache, CacheEntry<K, V>><br class="gmail_msg">
>> >> consumer)<br class="gmail_msg">
>> >><br class="gmail_msg">
>> >> This require the least amount of changes, however the user can't<br class="gmail_msg">
>> >> customize<br class="gmail_msg">
>> >> certain parameters that CacheStream currently provides (listed below -<br class="gmail_msg">
>> >> big<br class="gmail_msg">
>> >> one being filterKeys).<br class="gmail_msg">
>> >><br class="gmail_msg">
>> >> 2. CacheStream.forEachWithLock(BiConsumer<Cache, CacheEntry<K, V>><br class="gmail_msg">
>> >> consumer)<br class="gmail_msg">
>> >><br class="gmail_msg">
>> >> This method would only be allowed to be invoked on the Stream if no<br class="gmail_msg">
>> >> other<br class="gmail_msg">
>> >> intermediate operations were invoked, otherwise an exception would be<br class="gmail_msg">
>> >> thrown. This still gives us access to all of the CacheStream methods<br class="gmail_msg">
>> >> that<br class="gmail_msg">
>> >> aren't on the Stream interface (ie. sequentialDistribution,<br class="gmail_msg">
>> >> parallelDistribution, parallel, sequential, filterKeys,<br class="gmail_msg">
>> >> filterKeySegments,<br class="gmail_msg">
>> >> distributedBatchSize, disableRehashAware, timeout).<br class="gmail_msg">
>> >><br class="gmail_msg">
>> >> 3. LockedStream<CacheEntry<K, V>> AdvancedCache.lockedStream()<br class="gmail_msg">
>> >><br class="gmail_msg">
>> >> This requires the most changes, however the API would be the most<br class="gmail_msg">
>> >> explicit.<br class="gmail_msg">
>> >> In this case the LockedStream would only have the methods on it that<br class="gmail_msg">
>> >> are<br class="gmail_msg">
>> >> able to be invoked as noted above and forEach.<br class="gmail_msg">
>> >><br class="gmail_msg">
>> >> I personally feel that #3 might be the cleanest, but obviously requires<br class="gmail_msg">
>> >> adding more classes. Let me know what you guys think and if you think<br class="gmail_msg">
>> >> the<br class="gmail_msg">
>> >> optimistic exclusion is acceptable.<br class="gmail_msg">
>> >><br class="gmail_msg">
>> >> Thanks,<br class="gmail_msg">
>> >><br class="gmail_msg">
>> >> - Will<br class="gmail_msg">
>> >><br class="gmail_msg">
>> >> _______________________________________________<br class="gmail_msg">
>> >> infinispan-dev mailing list<br class="gmail_msg">
>> >> <a href="mailto:infinispan-dev@lists.jboss.org" class="gmail_msg" target="_blank">infinispan-dev@lists.jboss.org</a><br class="gmail_msg">
>> >> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br class="gmail_msg">
>> > _______________________________________________<br class="gmail_msg">
>> > infinispan-dev mailing list<br class="gmail_msg">
>> > <a href="mailto:infinispan-dev@lists.jboss.org" class="gmail_msg" target="_blank">infinispan-dev@lists.jboss.org</a><br class="gmail_msg">
>> > <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>> _______________________________________________<br class="gmail_msg">
>> infinispan-dev mailing list<br class="gmail_msg">
>> <a href="mailto:infinispan-dev@lists.jboss.org" class="gmail_msg" target="_blank">infinispan-dev@lists.jboss.org</a><br class="gmail_msg">
>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> _______________________________________________<br class="gmail_msg">
> infinispan-dev mailing list<br class="gmail_msg">
> <a href="mailto:infinispan-dev@lists.jboss.org" class="gmail_msg" target="_blank">infinispan-dev@lists.jboss.org</a><br class="gmail_msg">
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br class="gmail_msg">
<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
infinispan-dev mailing list<br class="gmail_msg">
<a href="mailto:infinispan-dev@lists.jboss.org" class="gmail_msg" target="_blank">infinispan-dev@lists.jboss.org</a><br class="gmail_msg">
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a></blockquote></div></div>