Ah, Singleton. Poor, overused, abused, bruised and battered Mr Singleton. They hire him for all kinds of things, even if he can't really do much good at all. And sometime later everyone's upset with him about the work he's done, even though he just did the job he was asked to do. You must feel sorry for Mr Singleton.
Not a good idea (you saw that coming, right?)
Of all the GoF
patterns, Singleton is the most abused. Singletons are appropriate when there is a fundamental reason why you can and should have only one instance of a given class. The fact that you happen to need only one in a particular case isn't good enough. There must be a reason that is fundamental to your design.
There isn't. Worse, a Singleton is harmful.
Reusability is once again a keyword here. How many database-driven applications do you know that can make do with just one database table? With local databases, nothing prevents you from using as many Data instances as you like, each representing a table. If LockManager were a Singleton, you would be restricted to just a single remote Data instance per server, reducing reusability to, erm, well, just about zero.
A one-per-Data "Singleton" would be fine, but a real, one-per-JVM Singleton is surely a mistake.
- Peter