OK, no one should have to tell an engineer to use caching. If you’re dealing with non-trivial amounts of data, and have a reasonable requirement for availability, you’ll need caching. The real issue is what, and how. The what depends on your situation. The how? Well, I’ve always thought it was obvious: ehcache. I’ve been using it as my 2nd-level cache provider for years. As cache providers go, it’s done well by me.
Well, now Greg Luck’s taking it to the next level. By moving to a minimum JDK of 1.5, he’ll be able to remove all dependencies. Also, ehcache-1.5 was a performant module. Now, if his figures are right, ehcache-1.6 will truly obliterate its peers. It’s still in beta, 1.6 that is, but check it out.
Nice..tip.
Will have to check it out..I tried to put in Ehcache a while back but couldn’t figure out from the docs etc. (in the time i had) whether it was using SoftReferences – so I had abandoned it and quickly wrote my own which has been working great untouched for the longest time.
I will have to compare Echache’s performance with my CacheManager .. those numbers seem way too good to not switch over. Where do u think those kind of performance gains came from? – better concurrency and/or better hashmap alogrithm? both seem like a tight squeeze for further performance improvements.
Yeah, it seems 1.5’s CopyOnWriteArray and ConcurrentHashMap are being used. Also, I think he made some other core tweaks too. But yeah, it’s a huge difference.
I’ve used the ehcache API directly too, about 9 months ago. It’s not too bad at all. Take another look.
My testing for basic caching needs (70 threads putting/getting the same things) Ehcache 1.6 is actually slower than my simple cache – but given all the other features it provides it may have improved a different configuration (e.g. cluster cache).