On Jan 4, 2011, at 5:48 PM, Manik Surtani wrote:
On 23 Dec 2010, at 16:48, Galder Zamarreño wrote:
> Hi,
>
> Re:
https://issues.jboss.org/browse/ISPN-841
>
> The issue here is the fact that if you call a TreeCache operation passing flags, you
want this flags to apply to all cache operations encompassing the tree cache op. Now, the
thing to remember about flags is that they get cleared after each cache invocation, so we
must somehow pass flags around to all methods that operate on the cache as a result of a
treecache.put for example.
>
> A rudimentary way to do so would be to pass Flag... to all methods involved which is
not pretty and hard to maintain. An alternative would be to have some flags thread local
that gets populated on start of tree cache operation and gets cleared in the end of the
operation. Although this might work, isn't this very similar to what CacheDelegate
does to maintain flags except that instead of keeping them for a cache invocation, it
would keep them hanging around until the end of the operation? TreeCache operations are
bounded by start/stop atomic calls that are essentially calls to start/stop batches. So,
it seems to me that what this is asking for is for a wider functionality to keep flags for
the duration of a transaction/batch, which would most likely be solved better in core/
Hmm; flags are explicitly designed for per-invocation application. If we change this to
apply to an entire transaction in core (e.g., by storing the flags in a transaction
context rather than an invocation context) it will break a lot of existing code.
I was not advocating for changing the meaning of flags, but rather adding to it. IOW, have
the ability to set flags on a per invocation basis is definitely needed, but maybe core
could also benefit from having the ability to set a flag for a tx, so have the two options
available somehow. I'm just saying this out loud in case there's any other such
use cases elsewhere apart from tree cache.
I think it cannot/should not be solved in core but rather in the TreeCache. A thread
local makes sense.
Ok. If some other component needs a similar thing, we'd then think about it again.
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache