Normally we use singleton instance for business / dao layer. What is the reason behind pooling stateless session beans in case of EJBs?
+2
A:
The "stateless" in the name refers to session conversation state, i.e. state that persists between invocations of the bean, retained for the duration of the session. However, stateless session beans are still permitted to have instance variables. Those instance variables should not relate to the conversation state, but are "shared" between clients.
In other words, stateless session beans are not guaranteed thread safe.
As a result, the container should ensure that only one thread is executing a given instance of a stateless session bean at one time, hence the need for a pool of them.
skaffman
2009-11-13 10:48:24
I think that instance variables do retain their values between invocations - the instance just lives in the pool. They can be used for caching non-conversational resources. Agree that Session Beans are explictly not thread safe, and when used in accordance with the EJB programming model the container does ensure that one thread/request at at time is serviced by an instance.
djna
2009-11-13 10:54:50
Good point, I've edited the answer accordingly.
skaffman
2009-11-13 11:03:44
arg, sorry, so did I.
djna
2009-11-13 11:08:14
Note that here is no guarantee that the variable still has the value, so don't rely on it. At any time between method calls on the bean, the container may indeed throw the bean out of the pool of available beans and destroy it.
Pascal Thivent
2009-11-13 11:20:04
+1
A:
- Because they are expensive to construct, often requiring access to external resources like databases, message queues etc..
- Because you don't want an unbounded number of them being created or else you will run out of resources
- So that the container can manage thread safety for you
Joel
2009-11-13 11:05:59