On May 31, 2013, at 3:37 PM, 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?
Currently SizeCommand, EntrySetCommand, ValuesCommand and KeySetCommand do not inherit
from FlagAffectedCommand which are used for commands that behavior is dependent upon
flags.
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.
^ This is a new scenario really. Normally all flagged operations where clustered. In fact,
FlagAffectedCommand was added to ship flags around, which we didn't used to do at the
beginning ;).
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?
Hmmm, since now all commands (local or clustered) can carry flags, what about making
VisitableCommand extend FlagAffectedCommand? That might be easier way to solve this
issue...
Thanks,
- Will
_______________________________________________
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