[infinispan-dev] Cache entry not invalidated callback?

[Manik Surtani]

On 28 Oct 2009, at 17:04, Galder Zamarreno wrote:

>
>
> 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?

Hmm, not sure how generally useful this is, so as to include it as a  
part of the core distro.  Adds bloat and complication to the  
notification/listener API.

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org