Hi,
Re:
https://issues.jboss.org/browse/ISPN-694
We've got a little problem here. Paul requires that entries that might have been
expired while in the cache store, when loaded, we send expiration notifications for them.
The problem is that expiration checking is currently done in the actual cache store
implementations, which makes supporting this (even outside the purgeExpired business)
specific to each cache store. Not ideal.
The alternative would be for CacheLoaderInterceptor to load, do the checks and then remove
the entries accordingly. The big problem here is that you're imposing a way to deal
with expiration handling for all cache store implementations, and some might be able to do
these checks and removals in a more efficient way if they were left to do it themselves.
For example, having to load all entries and then decide which are to expire might require
a lot of work, instead of potentially communicating directly with the cache store (imagine
a remote cache store…) and asking it to return all the entries filtered by those whose
expiry has not expired.
However, even if a cache store can do that, it would lead to loading only those entries
not expired, but then how do you send the notifications if those expired entries have been
filtered out? You probably need multiple load methods here...
@Paul, do you really need this for your use case?
The simplest thing to do might be to go for option 1, and let each cache store send
notifications for expired entries for the moment, and then in 6.0 revise not only the API
for purgeExpired, but also the API for load/loadAll() to find a way that, if any expiry
listeners are in place, a different method can be called on the cache store that signals
it to return all entries: both expired and non-expired, and then let the
CacheLoaderInterceptor send notifications from a central location.
Thoughts?
Cheers,
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org