[infinispan-dev] Stream operations under lock

William Burns mudokonman at gmail.com
Tue Mar 21 16:43:58 EDT 2017


On Tue, Mar 21, 2017 at 4:28 PM Tristan Tarrant <ttarrant at redhat.com> wrote:

>
>
> On 21/03/17 16:37, William Burns wrote:
> > Some users have expressed the need to have some sort of forEach
> > operation that is performed where the Consumer is called while holding
> > the lock for the given key and subsequently released after the Consumer
> > operation completes.
> >
> > Due to the nature of how streams work with retries and performing the
> > operation on the primary owner, this works out quite well with forEach
> > 1. AdvancedCache.forEachWithLock(BiConsumer<Cache, CacheEntry<K, V>>
> > consumer)
> >
> > This require the least amount of changes, however the user can't
> > customize certain parameters that CacheStream currently provides (listed
> > below - big one being filterKeys).
> >
> > 2. CacheStream.forEachWithLock(BiConsumer<Cache, CacheEntry<K, V>>
> consumer)
> >
> > This method would only be allowed to be invoked on the Stream if no
> > other intermediate operations were invoked, otherwise an exception would
> > be thrown. This still gives us access to all of the CacheStream methods
> > that aren't on the Stream interface (ie. sequentialDistribution,
> > parallelDistribution, parallel, sequential, filterKeys,
> > filterKeySegments, distributedBatchSize, disableRehashAware, timeout).
> >
> > 3. LockedStream<CacheEntry<K, V>> AdvancedCache.lockedStream()
> >
> > This requires the most changes, however the API would be the most
> > explicit. In this case the LockedStream would only have the methods on
> > it that are able to be invoked as noted above and forEach.
> >
> > I personally feel that #3 might be the cleanest, but obviously requires
> > adding more classes. Let me know what you guys think and if you think
> > the optimistic exclusion is acceptable.
>
> I prefer option 3, because I don't like UnsupportedOperationExceptions
> lurking until you hit runtime. Can you quantify the amount of extra
> effort here ?
>

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.

Also just to note you would still get an UnsupportedOperationException when
running in optimistic tx when invoking the method.


>
> Tristan
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> 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/20170321/0d762b4e/attachment-0001.html 


More information about the infinispan-dev mailing list