This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I am designing a way to cache objects which may or may not get persisted. The objects are tied to a user(id) and one user can have multiple objects floating around needing to be cached.
Is the best way to cache in memory is to just put the objects in a hash map or a more elegant utility has already been created for this...which takes care of many to many mapping, flushing the cache, etc.?
Synchronization is a concern with multi-threaded systems. I usually just synchronize the get & put methods on the cache, keep the map completely private, never let anybody else see an iterator or keyset or valueset.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Apr 14, 2006
Thanks for replying, Stan.
I also happened to look at ehcache on sf and I was wondering what is the primary usecase for choosing ehcache over a custom solution?
Joined: Jan 29, 2003
With just a quick look at the ehcache front page it seems to have many nifty features that I would not try to write myself. If you need the distributed or disk backed features, pick it for sure. I plan to read up on it further to see if it would replace a chunk of a vendor framework we use.
Under the Do The Simplest Thing That Can Possibly Work (for now) principle, you might choose a simple hashmap to start. Hide the implementation well behind your own interface and you can swap in ehcache or another distributed cache later if you find you need the features.