This week's book giveaway is in the Jobs Discussion forum.
We're giving away four copies of Java Interview Guide and have Anthony DePalma on-line!
See this thread for details.
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes Scalable Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "Scalable" Watch "Scalable" New topic


Raj Neets
Ranch Hand

Joined: Nov 12, 2002
Posts: 46
Hello Every one
Iam just getting started with EJB, so a basic ?
What does it mean that Stateful session bean is not scalable and stateless session is scalable. I understand what is stateless and statefull session bean. Usually when we talk about scalability in a component means adding new function or feature, but what it means in a bean.

Thank you
Nathaniel Stoddard
Ranch Hand

Joined: May 29, 2003
Posts: 1258
The main issue has to do with the fact that stateful session beans can't be passivated while they are involved in an open transaction. "Scalability" deals with the possibility of throwing more hardware at the problem in order to increase capacity. So, since stateful session beans are always going to be in memory if they are involved in open transactions, throwing more hardware/memory/etc will have no effect of the capacity of your application (as far as the stateful session beans are concerned).

Raj Neets
Ranch Hand

Joined: Nov 12, 2002
Posts: 46
Hello Nathaniel
But in Head First EJB by kathy on page 105, the author say it is possible to passivate the StateFull Session Bean.Iam just confused.
Kathy Sierra
Cowgirl and Author

Joined: Oct 10, 2002
Posts: 1589
Stateful session beans can be passivated, which is their only hope of scalability (although there will always be some level of a performance 'hit' for passivation/activation). But as Nathaniel mentioned, they can't be passivated while in a transaction. Now, you ideally want to design your app to keep transactions as short as possible, since EVERYTHING in your app will be hurt by long transactions, so the issue of transactions may not be a problem for your app that has stateful beans.
There *are* times when stateful beans, despite their weakness, may be the best choice for an app because you still have to put the conversational state *somewhere*, and the *other* options may end up being a worse choice than stateful beans. Some people use HTTP sessions, but that doesn't always save you much, and you are then FORCING your application to be a web app.
You could just keep passing the data back and forth as arguments to stateless methods, but then you might be affecting bandwidth... and of course you could just keep writing the state to a database, but THAT'S definitely a big performance there is a lot to consider.
I think my point is that while stateful beans have issues that make them *less* scalable than stateLESS beans, they should not be automatically dismissed as *bad*. Sometimes they might be the best option, and passivation *does* give them some help with scalability.
Sheesh, I think I sound like a cheerleader for stateful beans. I'm not really, but I do think they've gotten a worse reputation than they deserve... and *somebody* has to defend them
[ May 01, 2004: Message edited by: Kathy Sierra ]

Co-Author of Head First Design Patterns
Just a Jini girl living in a J2EE world.
Raj Neets
Ranch Hand

Joined: Nov 12, 2002
Posts: 46
Hello Kathy
Thank you for clearing my doubt. Now i understood the concept. I just started reading your book its good at the same time the lady/girl pictures in your book is also equally good.
I agree. Here's the link:
subject: Scalable
It's not a secret anymore!