• Bug
  • Status: Open
  • 2 Major
  • Resolution:
  • ehcache-core
  • cdennis
  • Reporter: ihrytsyuk
  • September 20, 2010
  • 0
  • Watchers: 0
  • October 11, 2011


Consider next cache configuration:

<cache name="popularCache"

and code snippet:

LiveCacheStatistics popularCacheStatistics = m_popularCache.getLiveCacheStatistics(); m_popularCache.put(new Element(“A”, 0)); m_popularCache.put(new Element(“A”, 0)); m_popularCache.put(new Element(“A”, 0)); m_popularCache.put(new Element(“A”, 0)); System.out.println(“PutCount: “ + popularCacheStatistics.getPutCount()); System.out.println(“UpdateCount: “ + popularCacheStatistics.getUpdateCount());

With ehcache-core-2.0.1 we receive:

PutCount: 1 UpdateCount: 3

With ehcache-core-2.2.0 we receive:

PutCount: 4 UpdateCount: 0 ```

Seems like ehcache-core-2.2.0 produces invalid statistical values.


Ivan Hrytsyuk 2010-09-20

If set maxElementsInMemory=”2” all works as expected.

Chris Dennis 2010-09-29

This is all down to a difference between when eviction happens relative to the put itself in the two versions. I will enter in to the semantics minefield with this guy sometime after code freeze, but I’m not certainly not going to fix this for Magnum, and to be honest I’m probably not going to fix it ever.

Chris Dennis 2010-10-11

The reason for the difference here is related to how eviction is performed by the two different versions of ehcache-core. In the new version the capacity eviction is performed prior to the put occurring instead of ‘after’. In that sense the existing element is evicted before the new element is added, hence the put is seen as a put to a now empty cache, and not an update of the existing element in the cache. Is this change in behavior causing problems beyond the perceived strange behavior in the statistics numbers?

Ivan Hrytsyuk 2010-10-12

I believe it’s critical for applications that use ehcache with strict number of elements and change it’s state based on events from CacheEventListener.