Originally posted by Namaste Sathi:
hi folks,
i am reading "Head First EJB" and wondering about the issues in the page 105 where it talks about scalability of stateful or statelss session beans. What does it mean for a bean to be scalable? or what is a bean sacalability? could you please shed some light in it?
Also, in the page 108 in a table, there are two stateful session beans column. is one of them meant to be Stateless?
and in page 109, why the client must have EJBObject interface and home stub class? having just EJBObject stub and Home stube would not be sufficient?
Howdy -- in this case, by 'scalability' we mean the ability to support growth as you get more and more clients trying to reach and use your beans. Stateful session beans are not *as* scalable as stateless beans, because with stateless beans you need only one bean per every ACTIVE client (i.e. client in the middle of a method call on the bean) and NOT one per every client that has a REFERENCE to that bean type's component interface. For example, with stateless beans, you can have 50 clients that have all done a create() on the AdviceBean's home, and received a component interface reference to that stateless bean. But the container needs to make only 10 AdviceBeans, because at any given time, only 10 of those clients are actually IN a method call on the bean. If there are 10 beans, and an 11th client tries to make a method call before the other 10 have completed, then the Container will just make another bean (unless the bean limit has been exceeded... completely vendor-dependent).
But with stateFUL beans, there must be one bean for EVERY client that has a reference to that bean's component interface. A stateFUL bean can service only one client, ever. But... "passivation" does provide at least *some* scalability for stateful beans, because you still have the same issue -- for every 50 clients with an active reference, only 10 might be in the middle of a method call. So what happens to the other 40 beans? Do they have to just sit there wasting RAM and other resources? Not if the Container uses passivation. With passivation, the Container can take a bean that is still considered 'valid' but isn't currently running a method for the client, and passivate the bean putting it into some kind of temporary secondary storage. Could be serialization (sloooow), or could be something much faster like a block memory copy.
Passivation still doesn't provide as much scalability as stateless, because there is still overhead involved in passivating/activating. Plus, a stateful bean in a transaction can never be passivated (but
you should design in such a way that you do NOT leave a stateful bean in a transaction at the end of a method!!). But there are cases where stateFUL beans are -- if not as scalable as stateLESS beans -- still gives you the best performance, if you need to maintain state. StateFUL beans are a lot more efficient than writing to a database, and sometimes more efficient than using the client to store the state (passing the conversational state into each method call on the now-stateLESS bean), and sometimes a better solution than using, say, an HTTPSession (because that means that your beans can be used ONLY by a web client).
OK, your other questions...
Yes, on page 108 that table is a typo. Make the first column STATELESS (I think this has been put on the O'Reilly errata page already.) Of course, as a 'learning opportunity', you should be able to tell from the part of the table that we filled in for you, that the first column should be stateless
On page 109, the client needs the
EJB object interface (your component interface) in order to compile, since that's what he gets back from the create() method. This might look confusing because of the way we wrote it... but basically the client needs the interfaces (home and component) at compile time AND runtime, and the stub classes at runtime (but not compile time).
Does that help? Sorry if we made things confusing... just keep asking questions!
cheers,
Kathy