This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
There are patterns you can use for this. If you are using JBoss and don't have to worry about other app resvers, you could just use their clustered singleton service. An alternative is to use RMI - create the singleton on one server and access it via RMI. But this will be a bottleneck. Perhaps you could consider why you need the singleton in the first place - its in an EJB environment so has to be read only. Is there therefore any real problem in having more than one?
Hi Paul, Thanks for your reply. I would like to understand how to maintain a single cache, to avoid cache synchronization like service locators for resource factories etc, across multiple server instances. I am aware that servers do this for us but what i want is to understand how it is achieved programmatically.
You said rmi with performance bottlenecks. Are you trying to imply that I should check on all server instances if the instance of the class I am dependent on exists using rmi? If not then pls explain your concept.
Also, I do not know in detail how servers implement the same. do they use some tools or congfiguration parameters etc ? So, if you or anyone else has an idea, all are welcome to help and contribute, thanks.
I think people refer to this as the "networked RMI object singleton" pattern, but don't quote me. What it involves is creating a remote service (i.e. an interface which extends java.rmi.Remote and an implementation which also extends javax.rmi.PortableRemoteObject) and deploying it on an app server. Now any part of your application can lookup the service and make remote calls to its public methods. Performance will always be a factor with singletons in a clustered envirenment (one instance of a class can conceivable have thousands of threads calling it). This is compounded when every call is via RMI. Added to this you've basically undermined the fail-over you get with clusters. Your service exists on one machine, it fails and all other instances in the cluster fail (in the sense that they can't use the service).
Also, I do not know in detail how servers implement the same
'fraid I don't know either, so can't help you there.