Hi Galder,
I agree with you, the command looks like a better place to place the
Flags. The only mismatch is with the origin where flags are enabled,
but I consider this as a convenience rather than a source of
surprising mismatches as I don't see how this API could lead to
unexpected results.
So the idea is in the future to avoid checking for flags in the
context but rather look in the command directly? So that we can avoid
copying them in the invocation context.
Sanne
On 3 January 2012 15:15, Galder Zamarreño <galder(a)jboss.org> wrote:
Hi,
Re:
https://github.com/galderz/infinispan/commit/fa419a1b22f56faa49e66588728f...
and
https://issues.jboss.org/browse/ISPN-1652
Back when Infinispan started, flags travelled down via thread locals and the context. Now
these flags are even part of the commands in order to travel accross different nodes.
As indicated in the JIRA and my comment, solving this problem by recreating context for
each command is complex (what type of context? remote? local?… I had a rather hacky
looking solution but broke tx recovery).
I do see however commands a more natural fit for flags. We use flags to invoke an
operation with those flags. To me, flags should really be migrated off context into
command and read them consistenly from command which btw solves this problem rather
easily.
I'm aware that I might be missing some odd use case where flags need to be in context
but can't think of it right now, hence this email thread, to see if someone else can
spot it.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev