After reading a lot about Session Beans my concepts have gone for a toss.
Please provide a simple scenario where your application would need Stateful for sure.
So if my code is :
class MyEJBClient {
// part 1
MyStateLessEJB statelessEjb = getStatelessEJBInstance();
statelessEjb.setCount(10);
statelessEjb.getCount(); // Should fetch me 10
// part 2
MyStateFullEJB statefullEjb = getStatefullEJBInstance();
statefullEjb.setCount(10);
MyStateFullEJB newStatefullEjb = getStatefullEJBInstance();
newStatefullEjb .getCount(); // Should fetch me 0
}
So in part 1 i have two calls to a stateless ejb and i still get the correct state, and
in part 2 i have two calls to two different stateful ejbs and i do not get the current/correct state of the bean using stateful.
Mustafa,
In example one, it only works because you happen to be getting the same bean without anyone calling it in between. What if you had multiple callers and they called setCount() before you call getCount(). The idea of stateless session beans is to not store state because it may not be there when you get back.
In example two, what does getStatefullEJBInstance() do? Depending on the logic, you may not be getting the same stateful bean.
In practice, I haven't needed stateful beans for anything. I have an HttpSession to store state in so I have no need to store it in the EJB layer.
"The set strikes me as something like the set of potatoes, radishes, farming, and lunch. " - a colleague's way of comparing both overlapping and disparate groups. made me laugh and thought of the ranch
Mustafa Garhi wrote:How do you get around 'multiple setters for my count problem' using stateful without using HttpSession etc.
Store a reference to the bean in the caller. I don't know how to say without using the HttpSession. I wouldn't use a stateless bean if I had an HttpSession.
Mustafa Garhi wrote:
And what do you mean by getting back to my bean - Does it mean trying to use the same bean in some other servlet say?
Yes. Suppose you only have one bean. Caller A sets it to 5. Caller B sets it o 7. Caller A gets the bean. It is now 7. When caller A got the same bean back, the value had changed out from under it.
"The set strikes me as something like the set of potatoes, radishes, farming, and lunch. " - a colleague's way of comparing both overlapping and disparate groups. made me laugh and thought of the ranch
Mustafa Garhi wrote:JB Considering the code again :
// part 1
MyStateLessEJB statelessEjb = getStatelessEJBInstance();
statelessEjb.setCount(10); // line 1
statelessEjb.getCount(); // line 2
Also assume there is no one else using this stateless.
Q. Is it possible that statelessEjb at line 1 and statelessEjb at line 2 are two different beans if i have a pool of say 10 for this stateless?
I don't think so. Once you have a reference to the bean, it shoull be the same object. Unless your app server is doing load balancing behind the scenes.
"The set strikes me as something like the set of potatoes, radishes, farming, and lunch. " - a colleague's way of comparing both overlapping and disparate groups. made me laugh and thought of the ranch
I thought I'd explain the concepts using a shopping cart example...
Say UserA, UserB and UserC are accessing a shopping website and adding items to the cart...
Method One: Using HttpSesison Only
Consider we have a plain Java class called ShoppingCart
If the sessions are maintained using HttpSession, for each user we would create a ShoppingCart object, add items to it, and store it as a session attribute.
Now note that the ShoppingCart object is in the web-tier.
Consider the ShoppingCart class here is a Stateful EJB
For each user the ShoppingCart (stateful EJB) is created (so the object now is in the Business Tier) and there is a HttpSession attribute holding a reference to this object.
So when userA adds an item, the ShoppingCart reference is taken from the session and the item is added...
likewise for UserB
Consider ShoppingCart to be a Stateless EJB here..
And the rest of the implementation is as above...
Though the reference in the HttpSession points to the same object every time, there is no guarantee that, that object was specific to one user. UserA, userB and UserC may all given the same object ! And hence the data is corrupted.
Why would one need a Stateful EJB at all.. ? It would look like MethodOne (using just HttpSession alone) suits most situations..
Yes. But Stateful EJBs help when the user has logged in using a different channel say WAP phone etc, and wants to know the state (Think of a railway ticket transaction scenario) i.e to maintain channel independent session
Also Stateful EJBs provides transaction service, security service, RMI, etc...
so when these features are required, Stateful EJBs would be very useful !
HTH,
Vishwa
This message was edited 3 times. Last update was at by Vishwanath Krishnamurthi
Considering userA is executing all the above, so for userB to be getting the same object,
the object should have gone back to the pool right? But it would not because we never let it go, using the session.
So how could the situation you mentioned occur bro?
Usually you don't get direct access to an ejb instance because that's handled by the ejb container. If you use something like
@EJB
ShoppingCart myStateless;
then myStateless will reference a proxy object and a method call like myStateless.addToCart(item); will result in a communication between the proxy object and the ejb container. Then the container can choose any instance of the stateless bean from the pool that finally performs addToCart method.
In contrast, if ShoppingCart would be a stateful session bean then the ejb container would use the same bean instance for each method invoked on myStateless.
Is it possible that statelessEjb at 1 and statelessEjb at 2 are two different beans from the pool?
It's possible that the methods calls in lines 1, 2 are performed by different bean instances from the pool.
"The set strikes me as something like the set of potatoes, radishes, farming, and lunch. " - a colleague's way of comparing both overlapping and disparate groups. made me laugh and thought of the ranch