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(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.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