[infinispan-dev] BdbjeCacheStore and JdbmCacheStore getExpiryTime todos

Galder Zamarreno galder.zamarreno at redhat.com
Wed Sep 16 05:03:30 EDT 2009


Hi,

I'm looking at the TODOs in the Infinispan code base and I've seen 
BdbjeCacheStore and JdbmCacheStore doing the following:

         long expiry = entry.getExpiryTime();
         if (entry.getMaxIdle() > 0) {
             // TODO do we need both?
             expiry = entry.getMaxIdle() + System.currentTimeMillis();
         }
         Long at = new Long(expiry);
         Object key = entry.getKey();
         expiryMap.put(at, key);

They use this expiry time as key in a expiryMap that they purge when 
they need to expire entries from the cache store:

     protected void purgeInternal() throws CacheLoaderException {
         try {
             Map<Long, Object> expired = 
expiryMap.tailMap(System.currentTimeMillis(), true);
             for (Map.Entry<Long, Object> entry : expired.entrySet()) {
                 expiryMap.remove(entry.getKey());
                 cacheMap.remove(entry.getValue());
             }
         } catch (RuntimeException caught) {
             throw convertToCacheLoaderException("error purging expired 
entries", caught);
         }
     }

InternalCacheEntry.getExpiryTime() says it has no meaning for entries 
with max idle but without lifespan. Couldn't this be extended to support 
max idle too?

For example: TransientCacheEntry.getExpiryTime() could return 
cachevalue.lastUsed + cachevalue.maxIdle. Obviously, this is not fixed 
and it's really a moving target based on when it's used, but wouldn't it 
avoid code like the one above?)

In the case where both max idle and lifespan are used, i.e. 
TransientMortalCacheEntry, getExpiryTime() would return whichever time 
is closer to expiration. So, if lifespan says it should expiry in Xms + 
1000ms but lastUsed + maxIdle says it should expiry in Xms + 2000ms, 
lifespan calculation would return, and viceversa.

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



More information about the infinispan-dev mailing list