A singleton class is a design pattern that prevents an object to be instantiated. This is rather cantraditionary in nature but nevertheless usefull in some circumstances. The singleton is a class that instantiates itself by means of a private static constructor. The object will be created at the very start of the application and can be retrieved by a public method that returns the only existing instance of this object. This can be usefull for many purpouses. For example a configuration that can change during operation, you do not want one thread of your application to read an updated version of your config data and another one an outdated version. In my project I thought of using a singleton bean to store and process access to the Knowledge Management Action Inbox. I wanted to dynamically change the categories shown. In a theoretical situation this would allow users to share an inbox or prevent multiple users to approve the same document, once approved by one user it can not be approved again by another. Shared access to a single resource, like in my example of a shared inbox, will have to be atomic or synchronized. The events of approving a document would be 1. Check if a document is approved. 2. If not, allow document approval. 3. approve document. 4. Set document's property to 'approved'. This is a rather crude simplification of reality, but I hope you agree that these four steps need to be executed without interferance of another user. Otherwise you will have the problem of one user starting the approval process and before this process is finished another user starts the same process. On the Q and A pages of sun the following statement is made: In general, the meaning of "singleton" in a distributed context is not entirely clear, particularly in the context of multiple Java virtual machines, clustered servers, and/or failover. This would apply to a SAP portal where multiple application instances run in multiple JVMs. Now the problems arise. The main is a prerformance problem. When you have a portal with many users simultaneously using your application they will have to wait for one users approval process to finish before another can. Another problem is the existance of a request scope when using your singleton bean to store settings. At class loader time there might not be a request scope at all so a call to this object will throw a nullpointer, or worse. The last problem can be mitigated by a function a colleague of mine, Eric Huisman, uses in his BeanFunctions class. The name of the method is pretty self explanatory: CheckOrSetupBean(). It checks if the bean exists and if it is set in the request scope, if so it returns the bean, if not it instanciates the bean and puts it in the request scope before returning it. Since I use this for almost all my beans my thought was to make this a method of a superclass bean and extend all beans in my project of this class. But this does not work for a singleton since its constructor is private. In an excellent article on this subject on JavaWorld Joshua Fox highlights two possible solutions. If you implement a factory class with a method that returns the singleton instance, you allow yourself flexibility in the runtime class of the return value, which can be either MySingleton or a subclass thereof. You may have to make the constructor nonprivate to make that work. Or you can have a SingletonFactory class with a globally accessible map of class names or Class objects to singleton instances. Again, the runtime type of the instances can be either the type indicated by the class name or a subclass, and the constructor will not be private. Now, as you can guess, my problems were not solved by this theoretical approach of the original problem. In fact, in my project I used neither singletons nor superclasses. It simply wasn't practical to experiment with this in a client situation. But my investigation leaves me with a few open questions. Is there any practical use for singletons at all in portal projects, and what are the pittfalls? Does any of you have experience or examples of these methods' use in a non-theoretic situation? Or are there other ways to work around the mentioned problems? I would love to share thoughts and ideas around this subject with you. On one hand for the love of solving problems with beautifull programming, on the other hand to see if anything good comes out. Because only faced with tough problems, you can truly say 'code is poetry'.
