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.
Thank-you again Satou and Nitesh. But I am not satisfied. I think that maybe do not have reason to use instance pool with stateless. Maybe this path was used to decrease the difficulty of implementation. I take this conclusion because I see that Spring can provide such services in a singleton mode.
Originally posted by Luciano A. Pozzo: Thank-you again Satou and Nitesh. But I am not satisfied. I think that maybe do not have reason to use instance pool with stateless. Maybe this path was used to decrease the difficulty of implementation. I take this conclusion because I see that Spring can provide such services in a singleton mode.
Hi Luciano, i am not sure about spring, but i dont think that in case of a singleton one would be able to store non-business related data in the stateless session bean, without bothering about multi-threading.
Luciano A. Pozzo
Joined: Jun 20, 2005
Nitesh , I don't know if I understood your question. But, for example, Spring manipulate the transaction context with ThreadLocal. We can use aspects for start, commit or roll-back the transaction. So the 'non business data', such transaction management, could be stored in a thread scope object, like ThreadLocal of jdk.
But if you want to hold state, that's fine. I agree that we can't use a singleton. But then we are talking about stateful session bean.
So, I don't see the services (transaction, security, etc) a reason for do a instance pool of objects that can be singleton.
Here is what i had written in the other thread that i pointed out:
This is what the ejb spec(Section 7.8) has to say for Stateless session beans
quote: The term �stateless� signifies that an instance has no state for a specific client. However, the instance variables of the instance can contain the state across client-invoked method calls. Examples of such states include an open database connection and an object reference to an EJB object.
So, essentially, its a business specific state that is forbidden to be maintained within a stateless session bean. One can store objects that might not be thread-safe for instance a reference to an Ejb object. The whole idea is that the bean provider is completely saved from being aware of any multi-threaded code in the container. One can write ejbs as POJOs and still enjoy the benefits of scalability.
When i said non-business related data i didn't point to the services offered by the container, but some objects used by the bean not for state maintenance but for processing the data. As quoted by the spec: "Examples of such states include an open database connection and an object reference to an EJB object."