Cache module has a bug on version 5.0.13

[fuqinqin]

I found that each time the AbstractCacheMap.snapshot method is called, the lastAccess property of the CacheObject object is reset to the current time, causing the originally expired CacheObject object to be revived. In addition, the method snapshot should not scan the expired cache, it is better to do a cleanup.

 public Map<K, V> snapshot() {
		final long stamp = lock.writeLock();
		try {
			Map<K, V> map = new HashMap<>(cacheMap.size());
			cacheMap.forEach((key, cacheValue) -> map.put(key, cacheValue.getObject()));
			return map;
		}
		finally {
			lock.unlockWrite(stamp);
		}
	}

[neroux]

I understand you are referring to

jodd/jodd-core/src/main/java/jodd/cache/AbstractCacheMap.java

Lines 314 to 324 in e451969

 public Map<K, V> snapshot() { 
 	final long stamp = lock.writeLock(); 
 	try { 
 		Map<K, V> map = new HashMap<>(cacheMap.size()); 
 		cacheMap.forEach((key, cacheValue) -> map.put(key, cacheValue.getObject())); 
 		return map; 
 	} 
 	finally { 
 		lock.unlockWrite(stamp); 
 	} 
 } 

So you are arguing a call to snapshot() should not update lastAccess as it is, implicitely, doing right now, because of the call to getObject

jodd/jodd-core/src/main/java/jodd/cache/AbstractCacheMap.java

Lines 66 to 70 in e451969

 V2 getObject() { 
 	lastAccess = System.currentTimeMillis(); 
 	accessCount++; 
 	return cachedObject; 
 } 

Why would argue so? After all it is accessing the cached object, even if not explicitely, but via the snapshot function.

Just trying to understand the reasoning behind your requests.

[Igor Spasić]

I guess it's because snapshot() should not actually get anything, it is more the matter of how to define the contract.

[neroux]

Well, snapshot() implicitly "gets" the value. But, yes, it is a matter of definition. If snapshot() should not update the respective fields, that would be something to be fixed :)

[Igor Spasić]

"When in doubt, add a flag" - Not Steve Jobs

:)))

[neroux]

Nice 👍