On May 31, 2013, at 4:11 PM, Sanne Grinovero <sanne(a)infinispan.org> wrote:
On 31 May 2013 14:37, William Burns <wburns(a)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?)
Sanne
> The problem is that FlagAffectedCommand currently extends VisitableCommand,
TopologyAffectedCommand, MetadataAwareCommand interfaces. These interfaces do not really
apply to the commands I am working on as they are local only. I was planning on removing
the extended interfaces from the FlagAffectedCommand interface and update all the commands
that implement this interface currently to make sure they still properly implement the
additional interfaces. Searching for instanceof FlagAffectedCommand it also appears that
all current references should be alright after refactoring. Once these interfaces are
decoupled I can add the FlagAffectedCommand interface to the SizeCommand, EntrySetCommand,
ValuesCommand and KeySetCommand and subsequently to the CommandFactory and my changes
should be good.
>
> Any opinions or concerns?
>
> Thanks,
>
> - Will
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org