I need to have a single instance of an EJB in my Application Server. Can anybody tell me how to do this?
(better known as Singleton)
Are there any possibilities to set the max numbers of instances in the Deployment Descriptor?
the way to get a bean work as single ton is to enforce only on instance of the bean in the app server, using deployment descriptor. now each app server vendor will have their own way of doin that using probably a configuration console or deployement tool console.
Can't we have a class which holds the remote handle of this ejb in a vector?
We define a class let's say RemoteFactory
this class will have
A variable of type Vector to hold the handle of remote.
A static variable of type RemoteFactory
A static method which will return the instance of RemoteFactory
This method will check whether an instance of RemoteFactory was already created or not. If not it will instantiate it and save the reference in the static variable (described earlier). (This will make the RemoteFactory a singleton also)
A method which will return the handle of the remote whenever needed.
This method should check whether the vector is empty of not. If the vector is empty then it needs to do all the JNDI look ups and stuff to get the remote, store it in the vector and return the handle to the caller.
If you want more than one instance (this is where vector comes handy), you can put as many handles as you want in the vector, before you start returing the handles from the vector.
It's not a good idea to make EJB singelton (either by setting max number of instances to 1 in deployment descriptor or by storing a handle).
I think you might need only a particular part of code to be singelton (synchronized maybe). In that case you might define a class and make that singelton and put the code whatever you want to make it as singelton. And make the method synchronized.
EJB spec recommends not to make EJB's synchronized but you can make helper classes for EJB's synchronized and singelton.
Am curious to know the reasons for not storing the handle. As we can easily make that class fault tolerant also, in case the bean dies for some reason
1. If 2 threads hold the same handle and invoke a method on the bean it throws remote exception( to avoid this you have to make the getter and setter methods for the handle as synchronized).
2. If a system exception is thrown the bean gets discarded by the container and you still hold the handle and when you invoke a method it throws ObjectNotFoundException. Some application servers (I think) might handle by assigning to another instance if previous object is discarded and this is ok in case os stateless and entity beans. But it will have seriuous problem if it is stateful(because it's dedicated to one client).
You can store a handle in a class or collection but there is more coding involved in this just to avoid getting remote exceptions and the code might also be confusing.