[jbosscache-dev] JBCACHE-1561 - how to get children or children names directly?

[Galder Zamarreno]

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 
actually. Example:

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 
loader.

>
> On 28 Dec 2009, at 10:23, Galder Zamarreno wrote:
>
>> Hi,
>>
>> 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.
>>
>> Thoughts?
>>
>> --
>> Galder Zamarreño
>> Sr. Software Engineer
>> Infinispan, JBoss Cache
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>