Unico Hommes wrote:
SourceForge.net wrote:
Project "ehcache" ('ehcache') has released the new version of package 'ehcache'.
I believe this was to be our cue for moving ehcache based store to the core and making it our default right? I have just updated our ehcache to the new release version but haven't yet moved it to the core. If noone objects I will move it to the core later.
One objection - below.
There still remains one FIXME in the EHCache store implementation though. Method free() hasn't been implemented. AFAIK this one is called by the StoreJanitor to do its work. However, although it works a little different from ours, EHCache has its own kind of janitor mechanism that operates on the basis of time-to-live and time-to-idle expiry strategies. Will this be sufficient or should we try to come up with some sort of implementation of the free() method?
No, it won't be sufficient. Janitor checks that JVM is not starving, and cache *must* react on low-memory condition regardless of time-to-live and other bells-and-wistles.
In the future Janitor should be hooked into JVM monitoring API: http://java.sun.com/j2se/1.5.0/docs/api/java/lang/management/MemoryMXBean.html
And then the sky is the limit ;-)
Vadim
Another thing to keep in mind is that EHCacheStore cannot be used in the role of a transient store. This is because it requires entries to be Serializable even if it is configured not to be persistence enabled. I will file an enhancement request to the ehcache guys like we did with JCS at the time, to remove this requirement.
-- Unico
