[infinispan-dev] Cache entry not invalidated callback?

[Galder Zamarreno]

On 10/28/2009 05:50 PM, Manik Surtani wrote:
>
> On 28 Oct 2009, at 09:29, Galder Zamarreno wrote:
>
>> Hi,
>>
>> Re: Porting over
>> http://opensource.atlassian.com/projects/hibernate/browse/HHH-3818 to
>> Infinispan 2nd level cache.
>>
>> For HHH-3818, Brian used the cache as a bus to notify that the cache
>> contents where invalid. To do so, he implemented cache entry modified
>> and invalidated callbacks that react to cache modifications or
>> invalidations where the FQN is an internal fqn which contains the
>> local
>> address.
>>
>> Now, the trick he uses for the invalidation is that on startup or
>> whenever there's a view change, he establishes these internal FQNs in
>> each node for each of the members in the cluster, i.e.
>> fqn=/test/com/foo/test/ENTITY/NODE/127.0.0.1:39104
>>
>> So, in an invalidation scenario, if you a node puts something on
>> /test/com/foo/test/ENTITY/NODE/127.0.0.1:39104, the other nodes have
>> at
>> least /test/com/foo/test/ENTITY/NODE/127.0.0.1:39104 created on their
>> caches which means that the invalidation callback works fine cos the
>> FQN
>> exists in other nodes.
>>
>> Now, in Infinispan's case, bearing in mind that there're no FQNs, I
>> could set up such keys when there's a view change too. However, I was
>> thinking of another alternative.
>>
>> Currently, cache invalidation callback fails on Infinispan because
>> when
>> you do a put on key=127.0.0.1:39104, the other nodes do not contain
>> the
>> key=127.0.0.1:39104, so no invalidation callback is received. So, my
>> suggestion is the following:
>>
>> Why not have a callback saying: "I attempted to do an invalidation on
>> k=x but k=x did not exist". Maybe something like
>> CacheEntryNotInvalidated callback? It looks to me that it'd be
>> relatively simply to implement such notification and would simplify
>> the
>> code on the Infinispan 2nd level cache provider.
>
> Hmm, where would you impl this callback?  As a part of the core
> Infinispan notification system?

The implementation would be somewhere in between RemoveCommand and 
InvalidateCommand. In RemoveCommand, after logging:

          log.trace("Nothing to remove since the entry is null or we 
have a null entry");

you'd have the possibility to notify that attempt was made to remove 
something but it wasn't there. I'm not sure whether it'd make a lot of 
sense to implement it for RemoveCommand so, we either add a notify 
method afterwards and make InvalidateCommand only provide a impl for it, 
or override perform() in IC, or somewhere in between, i.e. wrap code 
within the if (e == null || e.isNull()) into a method that is overriden 
by IC.

Thoughts?

> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-- 
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache