This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Hi All, Cud any one plz answer these questions.I am new (novice) to this. Why does Stateless Session bean not store its state even though it has ejbActivate and ejbPassivate ? and How does Stateful Session bean store its state ? Also can anyone suggest me some sites where I can get some gud stuff on EJB with examples. Thanks and Regards
Because both Stateless and Statefull Session beans SessionBean interface, both have ejbActivate() and ejbPassivate(). The stateless session bean simply does not use them. Statefull session bean stores it's state through serialization.
[ December 23, 2003: Message edited by: sergiu truta ]
...watch me...as I'm walking the path...
Joined: Aug 29, 2003
Hi, Thanks sergiu.I hope it will help me alot in future. But I still have some doubts. If Stateful Session bean store its state, then it must be using the ejbActivate() and ejbPassivate() methods. and how does it save its state thru serialization. Could u plz answer my queries. Thanks
bean (object) has two things, instance variable and methods. maintaining state is nothing but maintaining values of instance variables.
Why does Stateless Session bean not store its state even though it has ejbActivate and ejbPassivate ?
Stateless session bean can't have instance variable. And if a bean can't have instance variable there is nothing to maintain (state of object). I am also new, If have said something which is not corerect then, pls. correct me.
Howdy -- stateless session beans CAN have state... in the OO sense. Stateless session beans can maintain instance variable state just as well as stateFUL beans, or any other Java object. The reason that they are referred to as stateLESS is because they cannot maintain "client-specic state" (often referred to as "conversational" state). And this is only a limitation because there is not way to tie a specific stateless bean instance to a specific client. So a client could, for example, send a value to a stateless bean and the stateless bean could indeed set the value of an instance variable based on that client-sent value. And that's technically fine. But in reality, it won't mean anything, because the next time that client makes a call, the client might get a *different* bean instance... a bean instance that doesn't have that previously-sent instance variable value. Even though we say that a stateLESS session bean cannot remember state -- that is simply not true from a technical sense. The stateless bean can hold instance variable values... but it cannot TIE those values back to a specific client. So a stateless bean CAN remember state from the client, but the bean CANNOT REMEMBER WHICH CLIENT SENT THAT STATE! So client A sets a value in stateless bean One. Client B sets a different value in stateless bean Two. On the next business call, client A might get bean Two and client B might get bean One. The ejbPassivate() and ejbActivate() methods exist ONLY for stateFUL beans, and only to give stateFUL beans at least *some* small hope of being scalable. StateLESS beans do not need activation and passivation because they are pooled in such a way that you do not need one bean per each client. StateLESS beans: one bean per client in an *active method invocation on the bean" (and for every client with a reference to a stateLESS bean's component interface, only a very small percentage will actually BE in the middle of an active method invocation. Most of the time is spent BETWEEN invocations, in which case there can be far fewer beans than there are clients with REFERENCES to beans of that stateless type. StateFUL beans: one bean per client, period. Regardless of whether the client is in the middle of an invocation or not, there MUST be a bean tied to that client. That's what passivation and activation are for... to allow some of the beans to be passivated (which could be serialization, although we hope it is something more efficient like a direct copy of memory, for example) while the client is sitting there and not actively in a method call on the bean. But since the bean is tied directly to the client, every single stateFUL bean must be able to maintain state (you wouldn't want the contents of someone else's shopping cart to suddenly end up as YOUR shopping cart state, and vice-versa...) Bottom line: can stateless beans have state? Yes, absolutely, if you define "state" in the OO sense (meaning an instance variable, in this case) and they often do (could be a database connection, for example, or the value of an environment entry or a reference to an entity bean or... anything EXCEPT client-*specific* state. Good question, though And this is a very common misconception (that stateless beans can't maintain instance variable state) because of the name "stateLESS". So wherever you see the phrase "stateless session bean" do a mental search-and-replace and think instead "no-client-specific-state session bean" cheers, Kathy