We are developing a J2ee banking application using IBM Websphere. The application needs to connect to the EIS system using sockets. How can we implement a pool of open client sockets. Is it OK if we start separate threads that connects to the EIS system, we can start new threads when load increases and disconnect & stop the thread when not needed.Any component that needs access to the EIS system can get a handle from the common pool use it to communicate with the EIS and return it to the pool after use. How can we start these threads at application server startup. I have also read that its not a good idea to create and manage user threads in a J2EE application. What alternatives do we have. Any help/advice will be highly appreciated. Thanks in advance.
I think the best idea is to implement the socket communication as a Stateless SessionBean. Open one socket per SLSB, and let the server's instance pool be used as an indirect socket pool. I have used this, and it works fine!
Create the socket in ejbCreate() and close it in ejbRemove(). Check the details of the SLSB life cycle in the spec!
However, be aware of transaction properties! Supported by the socket communication you are using??
You should not create or use threads within an EJB.
Assuming no clustering is needed , there are basically two ways that I can think of which you can try :
1. Create a Singleton object that dispenses the connection. Use threads internally within the Singleton object. You can get a reference of the Singleton within the EJB.
2. Same as above , except that you bind the Singleton object to the JNDI tree. Inside the EJB , use JNDI to lookup the Singleton and get the connection from the Singleton.
Note that the above two solutions centralizes the thread management within the Singleton object and not within the EJB itself. Indirectly , threads are used in EJB , but it is via the Singleton. The reason that it is not a good idea to use threads within EJBs is because threads are a limited resource and it should be managed properly (the app server itself creates threads and if the user application creates thread , that could limit the threads available to the app server) . The above solution at least gives you a way to manage your threads to suit your execution environment.
As for the question of starting the threads on server startup , I am not familiar with Websphere , so I can't give any comment. I know you can do that in Weblogic via its custom Startup classes , so chances are high that Websphere would have some way to do that was well.
but as far as I know, even the usage of singletone is prohibited inside the EJB environment (as a policy). The reason being that EJB's can span across multiple phyisical m/c for load balancing purposes. In that case the singletone object is not really a singletone anymore.
Partially correct. Load balancing and clustering issues are not addressed in the EJB specifications. These are EJB container implementation related issues. AFAIK , the specs do not prohibit Singletons.
However , I do agree with your statement multiple machines will render Singletons useless. But that is due to EJB load balancing and clustering issues , and not the prohibition of EJB specs itself.
Hence , I made a presumption statement in the posting stating that "Assuming no clustering is needed". :)
Come to think of it , it is acceptable that connection pools be kept a Singleton , relative to one Server