On 01/04/2010 12:34 PM, Manik Surtani wrote:
To get any accurate result for such an operation you would need to
consult the cache loader...
Hmmmm, generally yeah but in this case I suspect you don't want
Let's say you have 3 caches configured with SSCL and
pushWhenCoordinator=true, and they're pointing to the same shared NFS
cache loader whose contents are:
/e/f [akey, a value]
Let's say the coordinator dies and between that and the new coordinator
taking over, a put is done (fqn=/e/i [bkey, bvalue]) in the node that is
supposed to become coordinator. The new coordinator is not yet active,
so /e/i won't be pushed to the cache loader.
When the new coordinator finally takes over and tries to get children's
of /e, it checks the cache loader and it says that these are: [f], and
hence it doesn't push /e/i to the cache loader.
The counterpoint here is that if eviction has been set up, and during
the coordinator change, /e/f had been evicted, it could maybe mean that
either, /e/f is not in memory any more, or /e/f is there but it's empty.
This could be OK cos I only push any changes of data that is in memory,
so if /e/f is not there, or is empty, I do not push that to the cache
On 28 Dec 2009, at 10:23, Galder Zamarreno wrote:
> Re: https://jira.jboss.org/jira/browse/JBCACHE-1561
> Is there a way in JBC 3.x to get the children or children names without
> accessing the cache loader? peek() does not help here and
> Option.suppressPersistence only works at the CacheStoreInterceptor level.
> Clearly, implementing getChildrenDirect() is not the right thing to do
> since this is old PL/OL API. I'd lean towards either extending
> Option.suppressPersistence so that it also covers CacheLoaderInterceptor
> so that it doesn't get stuff from CL if that option is set to true.
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
> jbosscache-dev mailing list
Lead, JBoss Cache