Thanks Eric , for your feedback . I am aware of the fact that container takes care of duplicating the Session across the cluster . But then if I have 10 servers , it would be an big overhead as the server has to make 10 copies of Session object. If I maintain the user state on the App Server level (EJB) . I could manage to bring down this overhead . But then I need to roll out my own session implementation (which at Web Tier ,Servlet/JSP container already implemnts). I am also aware of the fact that then my getAttribute() , setAttribute() calls would be network calls , and hence expensive
So this I m doing just to make sure that overhead of session object replication is not there. Now my question is .. do you feel I have some point here ??? or you feel that its more coding for less gain ?? -----Original Message----- From: Erik Price [mailto:[EMAIL PROTECTED] Sent: Thursday, July 10, 2003 9:09 PM To: Struts Users Mailing List Subject: Re: [OT] Session Management using EJB Nimish Chourey , Tidel Park - Chennai wrote: > Hi all , > I want to know if there are applications that implements Session > Management using EJB's rather then using the HttpSession on Web tier . > I want to know the pros and cons of this approach . For all the R&D that I > have done , it seems that this approach could be used when you are deploying > your application in a clustered environment , where it is really a over head > to duplicate the sessions on all the servers in the cluster . > Still I am in dilemma , whether to follow this approach or not ?? > This is really off topic , but I guess many of the developers here must have > come across this .. > Any sort of help , pointers is really appreciated . Nimish, I may be completely wrong about this, but here are my thoughts... As I'm sure you are aware, the purpose of the "session" in web applications is to maintain state between stateless HTTP requests. Thus, there is an HttpSession object available at the web tier (since presumably in 99.9% of situations, any HTTP requests will be handled at the web tier). In web applications that are not browser based (specifically, rich clients and applets), there is not the same need to persist state using a "session" object, because the state can be maintained in the client. Beyond the web tier, in the EJB tier, I don't think that there is a need to persist state beyond what session beans already offer. In other words, you can use a stateful session bean to perform a complicated action (or a stateless session bean for a simple action). But once the action is complete, you don't want the bean hanging around, it should be returned to the pool quickly to service the needs of other clients. The HttpSession is a comparatively lightweight object that you can use for persisting simple state information. I think that what you are really looking for is clustering for HttpSession objects, so that in a clustered environment, the HttpSession is replicated transparently. You can try to roll your own, but this is really an infrastructural area that is the responsibility of the container provider. Therefore, you should turn to your application server for this feature. (And I thought I heard that Tomcat is planning to have something like this in 5.0) Erik --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
