[infinispan-dev] Cache entry not invalidated callback?

Manik Surtani manik at jboss.org
Wed Nov 4 05:20:01 EST 2009


On 4 Nov 2009, at 09:04, Brian Stansberry  
<brian.stansberry at redhat.com> wrote:

>
> On Nov 4, 2009, at 4:48 PM, Galder Zamarreno wrote:
>
>>
>>
>> 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.
>>
>
> Agreed. (BTW I have other use cases, i.e. session management. ;) )
>
>> 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?
>>
>
> Can a boolean property be added to CacheEntryInvalidatedEvent?
>
> public boolean isKeyLocallyStored()
>
> or some better name.

Perhaps isSuccessful() ?

>
> BTW what happens with DIST and no L1 cache? Is an invalidation message
> even sent out?

No. Dist and no L1 will not result in any invalidation messages. But  
afaik the infinispan hibernate provider doesn't use dist, right Galder?

>> 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
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev




More information about the infinispan-dev mailing list