• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Bean Scalability!!!

 
Ranch Hand
Posts: 232
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Cowgirl and Author
Posts: 1589
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Ranch Hand
Posts: 183
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I was starting the book last night and came across that section. Thanks for the explanation
 
Ranch Hand
Posts: 312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1589
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 51
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
I am going down to the lab. Do NOT let anyone in. Not even this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic