<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 21, 2013 at 6:07 PM, Galder Zamarreño <span dir="ltr"><<a href="mailto:galder@redhat.com" target="_blank">galder@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On May 6, 2013, at 2:20 PM, Mircea Markus <<a href="mailto:mmarkus@redhat.com">mmarkus@redhat.com</a>> wrote:<br>
<br>
><br>
> On 3 May 2013, at 20:15, Paul Ferraro wrote:<br>
><br>
>> Is it essential? No - but it would simplify things on my end.<br>
>> If Infinispan can't implement expiration notifications, then I am forced<br>
>> to use immortal cache entries and perform expiration myself. To do<br>
>> this, I have to store meta information about the cache entry along with<br>
>> my actual cache values, which normally I would get for free via mortal<br>
>> cache entries.<br>
><br>
> In the scope of 5.2, what galder suggested was to fully support notifications for the entries in memory. In order to fully support your use case you'd need to add some code to trigger notifications in the cache store as well - I think that shouldn't be too difficult. What cache store implementation are you using any way?<br>
<br>
</div>^ Personally, I'd do in-memory entry expiration notifications for 5.2, and I'd leave cache store based entry expiration for 6.0, when we'll revisit cache store API, and we can address cache store based entry expiration notification properly.<br>
<br>
Agree everyone?<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>Agree, if you meant for 5.3 :)<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">
><br>
>><br>
>> So, it would be nice to have. If I have to wait for 6.0 for this,<br>
>> that's ok.<br>
>><br>
>> On Thu, 2013-05-02 at 17:03 +0200, Galder Zamarreño wrote:<br>
>>> Hi,<br>
>>><br>
>>> Re: <a href="https://issues.jboss.org/browse/ISPN-694" target="_blank">https://issues.jboss.org/browse/ISPN-694</a><br>
>>><br>
>>> We've got a little problem here. Paul requires that entries that might<br>
>>> have been expired while in the cache store, when loaded, we send<br>
>>> expiration notifications for them.<br>
>>><br>
>>> The problem is that expiration checking is currently done in the<br>
>>> actual cache store implementations, which makes supporting this (even<br>
>>> outside the purgeExpired business) specific to each cache store. Not<br>
>>> ideal.<br>
>>><br>
>>> The alternative would be for CacheLoaderInterceptor to load, do the<br>
>>> checks and then remove the entries accordingly. The big problem here<br>
>>> is that you're imposing a way to deal with expiration handling for all<br>
>>> cache store implementations, and some might be able to do these checks<br>
>>> and removals in a more efficient way if they were left to do it<br>
>>> themselves. For example, having to load all entries and then decide<br>
>>> which are to expire might require a lot of work, instead of<br>
>>> potentially communicating directly with the cache store (imagine a<br>
>>> remote cache store…) and asking it to return all the entries filtered<br>
>>> by those whose expiry has not expired.<br>
>>><br>
>>> However, even if a cache store can do that, it would lead to loading<br>
>>> only those entries not expired, but then how do you send the<br>
>>> notifications if those expired entries have been filtered out? You<br>
>>> probably need multiple load methods here...<br>
>>><br>
>>> @Paul, do you really need this for your use case?<br>
>>><br>
>>> The simplest thing to do might be to go for option 1, and let each<br>
>>> cache store send notifications for expired entries for the moment, and<br>
>>> then in 6.0 revise not only the API for purgeExpired, but also the API<br>
>>> for load/loadAll() to find a way that, if any expiry listeners are in<br>
>>> place, a different method can be called on the cache store that<br>
>>> signals it to return all entries: both expired and non-expired, and<br>
>>> then let the CacheLoaderInterceptor send notifications from a central<br>
>>> location.<br>
>>><br>
>>> Thoughts?<br>
>>><br>
>>> Cheers,<br>
>>> --<br>
>>> Galder Zamarreño<br>
>>> <a href="mailto:galder@redhat.com">galder@redhat.com</a><br>
>>> <a href="http://twitter.com/galderz" target="_blank">twitter.com/galderz</a><br>
>>><br>
>>> Project Lead, Escalante<br>
>>> <a href="http://escalante.io" target="_blank">http://escalante.io</a><br>
>>><br>
>>> Engineer, Infinispan<br>
>>> <a href="http://infinispan.org" target="_blank">http://infinispan.org</a><br>
>>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> infinispan-dev mailing list<br>
>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
><br>
> Cheers,<br>
> --<br>
> Mircea Markus<br>
> Infinispan lead (<a href="http://www.infinispan.org" target="_blank">www.infinispan.org</a>)<br>
><br>
><br>
><br>
><br>
<br>
<br>
--<br>
Galder Zamarreño<br>
<a href="mailto:galder@redhat.com">galder@redhat.com</a><br>
<a href="http://twitter.com/galderz" target="_blank">twitter.com/galderz</a><br>
<br>
Project Lead, Escalante<br>
<a href="http://escalante.io" target="_blank">http://escalante.io</a><br>
<br>
Engineer, Infinispan<br>
<a href="http://infinispan.org" target="_blank">http://infinispan.org</a><br>
<br>
<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</div></div></blockquote></div><br></div></div>