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 and other Java EE Technologies and the fly likes Storing Conversational information in J2EE project Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Storing Conversational information in J2EE project" Watch "Storing Conversational information in J2EE project" New topic
Author

Storing Conversational information in J2EE project

mini mehta
Ranch Hand

Joined: Oct 22, 2000
Posts: 120
Hi
Can you guys give me insight into how you people store the conversational information in application using JSP in presentation and EJB in business layer. Do you still store the conversation state in JSP using HttpSession object even though you could use Stateful session beans or you divide the state accross the Server Pages and Enterprise beans.
Regards
Mini
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
Conversational state goes in the HttpSession. Only persistent state goes in Entity beans -- I personally never use Stateful Session beans and do not recommend their use.
Kyle


Kyle Brown, Author of Persistence in the Enterprise and Enterprise Java Programming with IBM Websphere, 2nd Edition
See my homepage at http://www.kyle-brown.com/ for other WebSphere information.
Peter Storch
Ranch Hand

Joined: Jun 12, 2003
Posts: 74
We use a Stateful Session Bean in this scenario and have quite good experiance with that.
We belive that the EJB container can handle the Session data in a better way than the Web container can with the HttpSession. The EJB container has built in capabilities of passivation and management of the resource consumption.
Don't be fooled by other people saying "Stateful Session Beans are evil".
Try it, measure the performance and make your own decisions.
[ April 16, 2004: Message edited by: Peter Storch ]
mini mehta
Ranch Hand

Joined: Oct 22, 2000
Posts: 120
Originally posted by Kyle Brown:
Conversational state goes in the HttpSession. Only persistent state goes in Entity beans -- I personally never use Stateful Session beans and do not recommend their use.
Kyle

Thanks for your answer, but is there any reason why you do not recommed Stateful Session beans?
What would you recommend in the application which has web client as well a Swing client. In that case, wouldn't you put the state in Stateful session beans?
Mini
[ April 16, 2004: Message edited by: mini mehta ]
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
Originally posted by Peter Storch:
We use a Stateful Session Bean in this scenario and have quite good experiance with that.
We belive that the EJB container can handle the Session data in a better way than the Web container can with the HttpSession. The EJB container has built in capabilities of passivation and management of the resource consumption.
Don't be fooled by other people saying "Stateful Session Beans are evil".
Try it, measure the performance and make your own decisions.
[ April 16, 2004: Message edited by: Peter Storch ]

Here are the problems:
(1) All commercially available web containers also feature passivation and automatic failover of HttpSession data. Most also limit the number of HttpSessions in-memory at any time just as they do EJB's.
(2) Only a few EJB containers feature automatic failover of Stateful session bean data.
From the tests we've run at IBM, there is no difference in the performance of storing state in the EJB vs. Web container. The issue is one of failover. If you want a solution that will perform, scale and also failover properly in the most containers, go with the HttpSession.
Kyle
P.S. As for Swing clients -- keep the conversational state in the client...
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
Oh, and I haven't even gotten to the point of asking how you keep hold of the reference to the stateful session bean...if you have a web client the only place to store the reference is -- of course -- the HttpSession.
So another argument against them is if you're already having to use the HttpSession just to store the reference to the Session bean, why use the stateful session bean?
Kyle
Peter Storch
Ranch Hand

Joined: Jun 12, 2003
Posts: 74
Originally posted by Kyle Brown:
So another argument against them is if you're already having to use the HttpSession just to store the reference to the Session bean, why use the stateful session bean?


The same way you can argue about the HttpSession. To have a HttpSession you need to keep a session id on the client (Cookie, hidden field or URL rewriting). So why use HttpSession when you can keep session data on the client?
It's always a matter of how much data do you have and where you need it.
Roland Barcia
author
Ranch Hand

Joined: Apr 15, 2004
Posts: 181
I agree with Kyle. Http Session is a state used to keep track of the user. Becuase the User interacts with presentation, it is almost better to keep user state at the highest level. Hence, in a GUI, there are performance gains to keeping state.
EJB's are located in the business layer and thus should be used for business logic. Thus should a business tasks keep track of the user state? Once Business function require user intervention and keeping data in-between state, you start going into workflow.
If you are using Stateful Session Beans to cache data, that is the wrong place to do it. Pure Data Caches should be synchronized from the source of the data and not be replicated across clusters. Synchroization of data caches accross a cluster should just replicate a dirty flag, much like the Pub/Sub Entity BEan synchronization cache we have in WebSphere Application Server.
Business Logic should pass the key information to the cache to access it. TO keep the business logic in an SOA manner, it should not maintain the key data.


Roland Barcia: IBM Distinguished Engineer, CTO Mobile for Lab Services
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Storing Conversational information in J2EE project