This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
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.
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).
Howdy, 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 hit...so 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 Cheers, Kathy [ May 01, 2004: Message edited by: Kathy Sierra ]
Co-Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0596007124/ref=jranch-20" target="_blank" rel="nofollow">"Head First Design Patterns"</a><br /> <br />Just a Jini girl living in a J2EE world.
Joined: Nov 12, 2002
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.