• New Feature
  • Status: Closed
  • 2 Major
  • Resolution: Won't Fix
  • ehcache-core
  • cdennis
  • Reporter: mganguli
  • August 19, 2010
  • 0
  • Watchers: 1
  • March 23, 2011
  • December 10, 2010


Currently the Ehcache Element version is a plain timestamp [System.currentTimeMillis()]based implementation. This does not reliably creates a different version for every mutation of the element. Consequently, while implementing write behind features developers have to come up with custom version-ing tactics to ensure the correct version gets reflected in the SOR/DB. This can be completely circumvented if the version field can be made an incremental value that is incremented under a lock. This will ensure each mutation produces a cluster wide unique version number that can be used to resolve scenarios mentioned above.


Fiona OShea 2010-10-28

Is this a good idea?

Chris Dennis 2010-12-10

The issue of Ehcache’s internal treatment of the ‘version’ attribute has been resolved by EHC-666. During the resolution of that it was decided that providing an internal versioning scheme would cause unnecessary overhead for all users. Instead we now leave the version value untouched so that it is entirely within the control of the user.