Like Ehcache itself I'll keep this blog lightweight.
Here is why you care:
- How Much/No OOME's - Specify how much data you want to cache in bytes for on heap unserialized objects. Ehcache keeps the cache under that size to avoid OOME's
- Runtime, Tune as needed - Specify total heap to use for cache and then, when you feel like it, tweak individual caches for optimal performance.
- CacheManager - Max Bytes on heap (Percentage of heap or fixed number)
- Cache - max bytes on heap (Percentage of CacheManager or fixed number)
- Lots of caches made easy - Use hundreds of caches without sizing each one individually
- Hibernate people, this means YOU.
- Did I mention NO OOME's
- Fence your heap - Like Virtualized Machines give your app's internals a percentage of the total heap and your users a percentage. Prevent the two from stomping each other.
- People who ship software to others TAKE NOTE.
- Pinning - Pin caches or entries to heap that need to always be available and extremely fast.
Who Should Care?
- Hibernate users
- Lots of caches, impossible to tune each individually
- Spring Annotations users
- Pick the amount of heap you want to dedicate to caching and then just mark the methods that need caching
- Software Shippers (Frameworks, Servers or Apps)
- Don't force users to size caches
- Reserve part of the heap for your internal state and assign a safe size for users
- Application Admins
- Monitor an application in production and do sizing/pinning where needed on the fly
Conclusions
Ehache and ARC are free, lightweight and likely already in your application (embedded in Spring, Hibernate, Cold Fusion and countless other servers and frameworks.) This is the most requested feature set in the history of Ehcache.
More Info:
