<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Mar 21, 2017 at 4:28 PM Tristan Tarrant <<a href="mailto:ttarrant@redhat.com">ttarrant@redhat.com</a>> wrote:<br></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">
On 21/03/17 16:37, William Burns wrote:<br class="gmail_msg">
> Some users have expressed the need to have some sort of forEach<br class="gmail_msg">
> operation that is performed where the Consumer is called while holding<br class="gmail_msg">
> the lock for the given key and subsequently released after the Consumer<br class="gmail_msg">
> operation 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">
> 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 certain parameters that CacheStream currently provides (listed<br class="gmail_msg">
> below - big one being filterKeys).<br class="gmail_msg">
><br class="gmail_msg">
> 2. CacheStream.forEachWithLock(BiConsumer<Cache, CacheEntry<K, V>> 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 intermediate operations were invoked, otherwise an exception would<br class="gmail_msg">
> be thrown. This still gives us access to all of the CacheStream methods<br class="gmail_msg">
> that aren't on the Stream interface (ie. sequentialDistribution,<br class="gmail_msg">
> parallelDistribution, parallel, sequential, filterKeys,<br class="gmail_msg">
> filterKeySegments, 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. In this case the LockedStream would only have the methods on<br class="gmail_msg">
> it that are 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 optimistic exclusion is acceptable.<br class="gmail_msg">
<br class="gmail_msg">
I prefer option 3, because I don't like UnsupportedOperationExceptions<br class="gmail_msg">
lurking until you hit runtime. Can you quantify the amount of extra<br class="gmail_msg">
effort here ?<br class="gmail_msg"></blockquote><div><br></div><div>I would probably add a new interface that defines the common methods between CacheStream and LockedStream (or whatever we call it). Then the actual LockedStream class should be a self contained class. Thinking about it more it shouldn't require more than a couple hundred extra lines of code. The hard part was just getting the locking to work with non tx and pessimistic tx, which is common to any impl.</div><div><br></div><div>Also just to note you would still get an UnsupportedOperationException when running in optimistic tx when invoking the method.</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">
Tristan<br class="gmail_msg">
<br class="gmail_msg">
--<br class="gmail_msg">
Tristan Tarrant<br class="gmail_msg">
Infinispan Lead<br class="gmail_msg">
JBoss, a division of Red Hat<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">
</blockquote></div></div>