[infinispan-dev] Cache entry not invalidated callback?

Galder Zamarreno galder at redhat.com
Wed Nov 4 03:48:49 EST 2009



On 11/04/2009 03:29 AM, Brian Stansberry wrote:
>
> On Nov 3, 2009, at 9:35 PM, Galder Zamarreno wrote:
>
>> Manik, I might still need the notification requested below.
>>
>> Brian, I'd like to know your thoughts on this since it might influence
>> your work for
>> http://opensource.atlassian.com/projects/hibernate/browse/HHH-4521
>> (actually, I think it does! see bottom)
>>
>
> Yep. I'm working on HHH-4521 now and I expect this to be a problem
> when I run the test for it.
>
>> If we were to handle evict(key) in such way that we only set the
>> invalid
>> state for that key, the invalidation event received remotely would
>> need
>> to somehow carry the key that needs to be invalidated. Now, this means
>> that without my proposed notification, you'd need to have a key
>> present
>> in the cache that is composed of address:key, since a key with simply
>> address would not be sufficient to figure out which key to invalidate.
>>
>> For evict all, this is much simpler cos key can simply be address and
>> each node can initialise on startup from their local address (or upon
>> viewChange). This means that when an evict all occurs, all address
>> instances reside in the cache, so invalidation works fine.
>>
>> However, for evict(key), it simply is not feasible to have an
>> address:key key for each key present in the cache in case it has to be
>> evicted, and without that, the cache invalidation listener event won't
>> get fired. Please also remember that the invalidation event in
>> Infinispan only carries the key (obviously!), so I cannot use the
>> value
>> part to add the key for example.
>>
>
> Yeah. For JBC I was going to remove the key from the Fqn and just use
> it as the value, but then realized this wouldn't work w/ invalidation.
>
>> My preferred solution here would be to have a notification like the
>> one
>> suggested below. That way I don't need to have address:key for every
>> cluster member and key in the cache, and I can see when a particular
>> key
>> was invalidated by an address.
>>
>> Other solutions include:
>> - treat evict(key) as evict all: that way the key does not have to
>> travel to other nodes since they clear the entire cache. That would
>> be a
>> bit too extreme.
>>
>> Thinking through it, I think you'd have the same issue with JBC based
>> 2nd level cache:
>>
>> Brian, When you evict a key, you do:
>> Fqn f = Fqn.fromRelativeElements(region, Internal.NODE, member  ==
>> null
>> ? Internal.LOCAL : member, key);
>> cache.put(f, ITEM, DUMMY);
>>
>> So the FQN contains the key and for it to be invalidated, you need an
>> fqn with the member address and key! So, you'd have the same issue.
>>
>
> Yes, unless JBC emits the notification even if the node didn't exist
> locally. Which I doubt.
>
> TBH, this whole thing of using cache data as a mechanism to pass
> notifications is a hack. Much nicer IMHO would be a nice SPI / plug
> point to allow applications to extend the set of commands. Let an app
> create an ExtensionCommand; if that comes in off the channel pass it
> off to the handler the application registered.
>
> A worse IMHO option to the notification bus hack is to have the
> Hibernate-Infinispan/JBC integration create a separate JGroups channel
> for these messages. If a JGroups ChannelFactory + shared transport is
> used, that's just yuck. If ChannelFactory/shared transport aren't
> used, it's just unworkable.

I agree that the best way to solve this would be for ISPN/JBC to allow 
extension of commands but I think this requires a fair bit of thinking 
and design to get it right. So, we'd need to design it, implement it and 
proof-test it with SPI impls for ISPN and JBC 2nd level caches.

That's why I suggested the emit notification when a remote invalidation 
does not found the node/key in the node where is trying to do the 
invalidation. I think this could be a good short term solution while we 
fix the real issue. I don't think it'd require a lot of code. The main 
issue with it is that such notification is a public API, so once we put 
it out, we have to carry on maintaining it.

WDYT?

I also agree that an extra JGroups channel wouldn't be the best thing 
here. It looks like an overkill to me.


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


More information about the infinispan-dev mailing list