This information would then be parsed and cached in a singleton through a lazy loading process and be available ...
there wasn't a need to provide the ability to provide a multion implementation of DB, allowing for the possibility of each having its own schema.
True, this isn't a requirement. But there isn't any reason to make it a singleton either, is there? The simplest thing, IMO, is to create a class that has a public constructor like normal.
Well, it's exactly how I implemented my multiton ... :-)
But I have a technical question about how to release those unique instances, because the first technique I thought about is not satisfactory :
Data instances are stored in a private static HashMap They are reference-counted (private int referenceCount) My static method Data getInstance(String dbFileName) increments the counter A public void releaseInstance() method decrements it, and if zero removes the instance from the HashMap
It is not OK, because I noticed that that design makes possible to build two (or more) different instances pointing to the same database file :
My question is : is it not a good use-case of WeakHashMap ?
No need for a releaseInstance() method anymore The Data instances may be safely copied in multiple Data variables if needed They are automatically removed from the WeakHashMap when all other references to them become unreachable
Is it OK ? I have no experience of WeakHashMap and moreover I wonder if there are not potential multi-threading issues, as WeakHashMap is documented as not synchronized. Does the garbage collector perform external synchronization when he decides to remove an entry ? Or is it safer to wrap it with Collections.synchronizedMap method ?
Thank for your advice,