Simple caching in singleton DAO

Question

Suppose I was to use a DAO like this in a web application. Different threads would be concurrently accessing this code from different servlets, struts actions, JSP pages, whatever.
import java.util.Map;
import java.util.HashMap;
public class CacheSingletonDAO {
     private static Map items = new HashMap();
     //----- Singleton Methods --------------------------------------------------
     private static final CacheSingletonDAO instance = new CacheSingletonDAO();
     private CacheSingletonDAO() {
          items.put("1","foo");
          items.put("2","bar");
     public static CacheSingletonDAO getInstance() {
          return instance;
     //----- Public Methods -----------------------------------------------------
     public String getItem(String key) {
          Object obj = items.get(key);
          if(obj != null && obj instanceof String) {
               return (String)obj;
          } else {
               return null;
     public Map getItems() {
          return items;
     public void addItem(String key, String item) {
          items.put(key,item);
}The code here is over simplified. For a real implementation of this, there would most likely be a private getItemsFromDB() method that the private constructor would call. I would also have a method like refreshCache() that would call the getItemsFromDB() method, so that I could call that to update the items HashMap with whatever is in the database. The addItem(String, String) method would first store the item in a database, then put item in the HashMap. Assume I would be using this in a single server, single JVM application. Are there any thread-safety or other problems/issues with code like this?

Answer 1

I don't think this logic necessarily follows. I agree
that the user must see all the entries in the
drop-down list, but that doesn't mean that this class
needs to hand the map over to the drop-down list
instance or the UI container. Instead, the UI could
ask this instance to write itself into the drop-down
list.I envisioned the DAO as the model in a MVC app. Writing the drop-down seems like it is a task for the view.
This is a very common sentiment among programmers.
"If you're code is written wrong, then it's not my
problem." I'm not saying that you're wrong to feel
this way, but in general projects get finished faster
when the interfaces between components or classes are
tight. That is, write an interface to your class
that helps people avoid coding mistakes. If
getItems().add() should not be coded then you should
try to make sure that it can't be.That makes sense.
This is a little better. Now when somebody else codes
getItems().add(), their code compiles (as it did
before) but when they run some test case (assuming
they test the right path) they will see an
UnsupportedOperationException instead of seeing some
occasional bad behaviour (as they would have seen
before). But better still, write an interface that
doesn't allow anybody else to code getItems().add() in
the first place. I'm not trying to make your life
more difficult, but in the long run doing this saves
time for everybody on your project.I see your point.
Would it be a reasonable
solution to write String[] getItemValues(), that
returns a copy of all the values currently in the
HashMap? Do you need to supply the user with key-value
pairs instead? Is there a way that you can return an
array of those things rather than the map?You are right, there is no reason I couldn't do that. Would this cause potential performance issues? I would think giving the client the a read-only reference to the hashmap would be faster than generating an array of Object each time.
>>
But then my original question still is do add and
refresh need to be synchronized? I can't think of
anything that would be bad if they weren't
synchronized, but maybe I am overlooking something.
What happens if someone calls the add method while
the refresh method is executing? I guess I need to
show more code to address that:
public void add(String key, String item) {
addItemToDB(key,item);
items.put(key.item);
public void refreshCache() {
items = getItemsFromDB();
}Assume addItemToDB() returns void and inserts myitem
into the database.
Assume getItemsFromDB() queries the DB for all the
items and returns a Map with all of the items.
Do these methods need to be synchronized?
You need to provide synchronization for the map, the
map has no synchronization of it's own.But just synchronizing add and refreshCache won't cut it, right? I think if things happend in this order I would have an issue:
1. Thread A calls refreshCache()
2. refreshCache() calls getItemsFromDB()
3. getItemsFromDB() internally has queried the DB, gotten a ResultSet and is building a collection from the result set, but the method isn't finished yet.
4. Thread B calls add()
5. add() calls addItemtoDB(key,item), which finishes
6. add() puts the item in the items HashMap
7. add() finished executing
8. getItemsFromDB() finishes executing and returns a collection, but the collection doesn't have the item add by Thread B's add()
9. refreshCache replaces the items HashMap with the collection returned from getItemsFromDB() and now the item that was added by Thread B's add() won't end up in the collection until next time refreshCache() is called.
This would be the case even if add() and refreshCache() were synchronized, right?