File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes Bean Scalability!!! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "Bean Scalability!!!" Watch "Bean Scalability!!!" New topic
Author

Bean Scalability!!!

Brian Smith
Ranch Hand

Joined: Oct 26, 2002
Posts: 232
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?
thanks.
[ November 18, 2003: Message edited by: Namaste Sathi ]
Kathy Sierra
Cowgirl and Author
Ranch Hand

Joined: Oct 10, 2002
Posts: 1572
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
Ed Tse
Ranch Hand

Joined: Sep 18, 2003
Posts: 183
I was starting the book last night and came across that section. Thanks for the explanation


SCJP, Pre-SCJD (URLyBird 1.3.1), Teradata Cert'd Prof
manish ahuja
Ranch Hand

Joined: Oct 23, 2003
Posts: 312
Hi Kathy
i have some questions to ask regarding the reply posted bu kathy.
actually this was 1 of my interview question in a top Indian IT co.
the 1st question is regarding saclability where you mention
--------
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).
--------
In this scenario what if my max bean limit is 10 & i get the 11 th request
what would happen . what would be the behaviour. do ellaborate a bit

2nd question is about activation/passivation

i would like to know the nitty gritty of how the container maps back to the actual
passivated content & retrieve state for that particular client
Rgrds
Manish
Kathy Sierra
Cowgirl and Author
Ranch Hand

Joined: Oct 10, 2002
Posts: 1572
Howdy...

In this scenario what if my max bean limit is 10 & i get the 11 th request
what would happen . what would be the behaviour. do ellaborate a bit

In most cases, it just means the client has to wait until one of those 10 beans finishes a method and can jump over to service that other client. As far as the client is concerned, the method call just *takes* longer.

2nd question is about activation/passivation
i would like to know the nitty gritty of how the container maps back to the actual
passivated content & retrieve state for that particular client

For this, we have no idea. This is completely dependent on how the vendor chooses to implement passivation/activation. So, there is nothing in the spec about how the Container should handle this, so there is no way to know unless:
A) Your Container documentation happens to tell you (probably not)
B) You work for the Container vendor
You can probably imagine lots of scenarios and different ways in which this could be implemented. Remember, too, that passivated beans will not survive a Container crash, so the passivate state is not stored permanently (again, that is according to the spec... your vendor might provide some special feature, like a sticker on the box that says, "NOW! With Crash-Proof Stateful beans!" but do not count on it
This is one of those features that is meant to be completely hidden from you. You *might* care how the vendor does it if you plan on using stateful beans and you want the best possible performance, but you couldn't *do* anything with knowledge of how the vendor does it. You probably just care about the benchmarks/performance of that Container, when tested on passivation and activation.
I want to point out, too, that setting limits for passivation/activation is NOT part of the spec, and is completely up to the vendor. So how, and even IF, you can tune passivation parameters (like, "Passivate when RAM gets dangerously low...") is not guaranteed. In other words, not all vendors will even give you a way to set a maximum bean limit (in fact, I think many do it more on resource levels rather than an actual bean count).
I hope this helps a little...
cheers,
Kathy
Steve Agarwal
Ranch Hand

Joined: Feb 02, 2003
Posts: 51
passivation / activation ???
my understanding without worrying about the provider.
1) these logic is used to keep the client processing alive over a period of time.
2) the data is serialized into the database or some storage which is again read using obejectread and objectwrite.
3) serialization helps bean to get free the resources for other users
4) container reads back the data after the session of client becomes active.
Steve
PS I havent taken transaction details as they are add on top of above explanation.
Q Some one asked me
1) What happens when some one changes name of stateless to statefull in DD.What would be the result.


SCJP1.4,SCWCD, SCBCD, SCEA part 1<br />"Its feels good to know the stuff in detail."
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Bean Scalability!!!