• Post Reply Bookmark Topic Watch Topic
  • New Topic

Stateless vs. Stateful Session Beans?  RSS feed

 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,
I'm trying to think through when it makes sense to use a stateful session bean versus simply storing state on the client side and using a stateless session bean instead.
I've gathered the following reasons why one would want to store state on the server versus the client:
- the state consists of remote references to entity beans, which you want to be invoked by the stateful session bean, and not the client directly
- your state takes up alot of memory, and your servlet container does not perform effective memory management (e.g. instance swapping) of servlet session objects
- you want more than one type of client UI to be able to leverage the same set of state information, i.e. the same workflow
Are these correct? Are there others?
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well,
Personally I think the first one (storing instance references to entities) is a wash, since you can always use a finder method to recover them from the primary keys. This will be no faster than holding the instances if you are using Option C caching (the most common one, which means throw away all data at the end of every transaction).
Also, I think the last one is a wash, since you're really not supposed to have more than ONE client hold on to a reference to a session bean. Passing around stateful bean references to multiple clients is rather dangerous...
The middle one, though -- yeah I agree with it. It's something I've done on more than one occasion. It also works when the total size of the session data is larger than what your servlet engine can reasonably handle efficiently.
Kyle

------------------
Kyle Brown,
Author of Enterprise Java (tm) Programming with IBM Websphere
See my homepage at http://members.aol.com/kgb1001001 for other WebSphere information.
 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Personally I think the first one (storing instance references to entities) is a wash, since you can always use a finder method to recover them from the primary keys. This will be no faster than holding the instances if you are using Option C caching (the most common one, which means throw away all data at the end of every transaction).
I'm honestly amazed at the knowledge some of the folks at JavaRanch, like yourself, possess. I wasn't aware of Commit Options A, B and C. But I looked it up in the EJB spec, and your comment makes perfect sense to me now. Thanks!
The middle one, though -- yeah I agree with it. It's something I've done on more than one occasion. It also works when the total size of the session data is larger than what your servlet engine can reasonably handle efficiently.
Do you know of any guidelines for computing an appropriate upper limit to how much data should be stored in a servlet session object? I.e. what variables should be considered (e.g. total system memory, number of concurrent users, servlet container...), and is there such a "formula" based on these variables?
Also, I think the last one is a wash, since you're really not supposed to have more than ONE client hold on to a reference to a session bean. Passing around stateful bean references to multiple clients is rather dangerous.
I think I worded the third item incorrectly. What I meant was that one might want to use a stateful session bean to standardize workflow among a number of different GUIs. So, for instance, a web client and a Java client could leverage different instances of the same stateful session bean to hold their workflow state, as opposed to managing their workflows on the client side thereby fostering potentially differing and inconsistent workflows amongst clients.
Thanks.
-Miftah

[This message has been edited by Miftah Khan (edited October 17, 2001).]
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!