[infinispan-dev] FlagAffectedCommand interface hierarchy (ISPN-761)

[Mircea Markus]

On 3 Jun 2013, at 14:27, Galder Zamarreño <galder at redhat.com> wrote:

> On May 31, 2013, at 4:11 PM, Sanne Grinovero <sanne at infinispan.org> wrote:
> 
>> On 31 May 2013 14:37, William Burns <wburns at redhat.com> wrote:
>>> While adding changes for cache methods (entrySet, keySet, values, size) to include passivated entries it had been pointed out to conditionally do these operations if flags such as SKIP_CACHE_STORE and SKIP_CACHE_LOAD were provided.  Also does anyone have any feedback on if both flags should apply or just say SKIP_CACHE_STORE?
>> 
>> Right, that could definitely be improved. I would expect both to be
>> needed as one mentions "store", the other "load", but in practice it
>> seems that SKIP_CACHE_STORE skips both operations. I think this should
>> at least be clarified in the javadocs.
>> 
>>> Currently SizeCommand, EntrySetCommand, ValuesCommand and KeySetCommand do not inherit from FlagAffectedCommand which are used for commands that behavior is dependent upon flags.
>> 
>> You just listed the most evil operations you can use in Infinispan.
>> All of these are inherently broken as we need to constantly clarify to
>> users that they only apply to the local datastore, which makes it even
>> trickier to test something on a single node and then expect it to work
>> on multiple nodes as well..
> 
> … which is why they're not included in JCache/JSR-107. All you have there is an iterator()...
> 
>> I know, we have warnings on javadoc but since it implements
>> ConcurrentMap and Map, these warnings are easily overseen.
>> 
>> So my doubt actually is, since these operations are fundamentally
>> unreliable, why should they include CacheStore s as well? IMHO they
>> should all throw a runtime exception to flag they are not supported.
>> I guess we don't throw such exceptions as they could be useful for
>> some metrics, but still I think it would be more appropriate to move
>> this responsibility to a statistics/monitoring API.
> 
> Indeed, they should be removed at some point and align ourselves closer to JCache on this occasion. +1 on being something about statistics/monitoring, which is done at the local level (tools can be used to aggregate results, or even map/reduce?)

Agreed. Infinispan 6.0 is quite loaded as it is, let's do it in next major.

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)