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 ?
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat