On 31 May 2013, at 15:11, Sanne Grinovero <[email protected]> wrote:
> On 31 May 2013 14:37, William Burns <[email protected]> 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.. > 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 these are very costly operations and using them should be done with care. I think they make sense at times, especially with local cache. Having them partially implemented creates confusion through the users. Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
