This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
What you can possibly do is to have the state information bundled into an object and store this object with an some id in a static hashtable external to EJB contained in a singleton class but this information must also be passed to the client so that the client can retrieve the state information.......... If persistence is required, then you may have to serialize the state information......... Other option is a good old one.......dump everything to database.... so that you get the same effect..... Literally, you end up doing the job of the container...... Hope this helps Rgds Muthu
Hi, The main difference that lies between the stateful,and stateless bean is the use of the bean instance.The container ensures that the ejbObject uses the same bean insatnce(ie the values of the instance variables) during the life cycle of the client in the stateful session bean. But in stateless the same client calling a different method on a bean may end up using a different instance.So to achieve the functionality of stateful in stateless copy the value of the instance variables to the bean each time a method is invoked on the bean by the client. If something is incorrect in the explanation provided, pl do let me know. Cheers Geeta
Joined: Apr 11, 2003
Thank you for the tips i guess it make perfect sense
Hint: stateless EJB. If a given EJB attempts to maintain state information inside itself, it's a stateful bean, whether so declared or not. And if it's not, the state may not get properly maintained, especially under heavy system load. A stateless EJB is an object of which there may be multiple identical instances. That is, if you dive into the bean pool and come up with one at random, you will get extactly the same results no matter how many times you grab a bean instance. The only way a stateless bean could achieve that quality is to have whatever state was being pushed in propagated to every other bean in the pool. Which, needless to say, could be really horrible in terms of overhead. Stateless Session EJBs are great as a repository for pure business logic. They have about the lighest overhead of any EJB. However if you need something that retains information between method calls, you should be using a stateful EJB - either a Stateful Session EJB, or, if persistency is important, an Entity EJB. [ April 22, 2003: Message edited by: Tim Holloway ]
Customer surveys are for companies who didn't pay proper attention to begin with.
A stateful session may have conversational state, that is, state belonging to a conversation with a client. Stateful session beans are designed to hold state for a client - each bean is unique, and can be passivated to conserve overhead. On the other hand, a stateless session bean may not hold conversational state for a client. Although it's called a "stateless" session bean, a stateless session bean could hold state in a general sense, but not for a single client. It could hold a reference to an external resource like a database connection, for example. Probably you can't directly achieve the functionality of a stateful session bean with a stateless session bean. But you could handle the client conversational state elsewhere, say in an HttpSession, or in the client application, or even in a database. Have a look at the EJB spec, section 7.2 for stateless session beans.