This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
The EJB spec mandates that the access to EJBs be thread safe. This means that multiple clients cannot be accessing the same instance of the stateless bean at the same time. One way to achieve this goal is to have a single instance of the bean and "wait" till each of the client completes the access to the bean before letting the next client in. This obviously isn't practical for real applications. That's where the pool comes into picture. A certain number of bean instances will be available in the pool and whenever a client wants access to the bean, an instance can be allocated from that pool. This way multiple clients will work on different instances of the stateless bean at the same time.
But for what reasons the specs mandates stateless session bean to be thread safe. For entity and Statefull this make sense. Stateless session bean will not have any instance variable. So the same instance can service multiple clients.
Gagandeep-Aryan Malhotra wrote:For entity and Statefull this make sense. Stateless session bean will not have any instance variable. So the same instance can service multiple clients.
Stateless bean can have instance variables (for example you can have fields within a stateless bean which can have injected values). However the clients or the bean methods themselves aren't expected to assume that the values changed in one business method invocation will be available during another business method invocation of the same bean.
Joined: May 29, 2012
Thanks for clearing doubt. It was of great help.
Can you please elaborate more on "injecting values".