Re: Maintaining Session in Application Server

[Juan Pablo Lorandi]

Title: Message

Mark, I don't see anything you quote that supports your initial assertion on using SFSBs:   "Not for something this trivial - stateful session beans are VERY expensive.  Just put whatever you want to persist in either context scope with a singleton or in entity beans that map to the appropriate db table(s)."   I have to agree with Victor here that SFSBs are fit for the purpose: keeping track of Session state in the App Server layer(s). Session objects (basically a HashMap) might be very trivial to build, but their usage patterns and activies are never trivial. Other objects may very well be Entity Beans for instance, but the usage patterns of session information (and incidentally as well, user credentials) are transversal to an application. They will be used many times inside the same request, by different pieces of code. That will spawn a non-trivial number of select/update statements to the DB. A singleton, even in a cluster-wide context scope means a number of Remote calls, so its overhead will be for all practical purposes about the same as an SFSB.   Furthermore, the assertions you've quoted aren't wrong. They're mostly the kind of advice I'd give a newbie. But general guidelines aren't to be used in all cases; specifically, these guidelines you've quoted are there to prevent coders new to EJBs and n-tiers into thinking that SFSBs are the equivalent to general classes in java (functionally, they *might* be, but performance wise the difference is huge). RAM usage isn't the only cost involved: Network resources and CPU time in both the client and the server are also critical.   Finally, the original poster said:   "We are currently working on J2EE application and we ar only dealing with Server side components. I want to maintain the session information in EJBS, how can I do that i.e. I want to provide the same functionality as HttpSession provides in Servlet. I would also like to know how it is going to work in cluster enviorment." Which will be the clients? JSP pages or your components will be reached by an application/other components? HttpSessions only make sense when using a stateless request/response protocol such as HTTP, but for an application or other components using yours there will be a permanent connection between one and another. Credentials will always be available. If you're using JSPs, just use the bundled HttpSession, and pass parameters correctly. Even if you wish to store all session information in a singleton cache, a SFSB or an EB, you'll need to have some unique identifier to retrieve your data (a key for the HashMap, a serialized javax.ejb.Handle instance, or a PK). Accessing "Http Session" data from an EJB isn't contemplated (not allowed nor prohibited) by the spec simply because EJBs aren't a conectionless based platform: you "connect" to a JNDI tree, get your components, operate on them, release them, disconnect from JNDI. Also, many EJBs have for clients other EJBs or simply applications. These wouldn't have any "Session" information, apart from their credentials. =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".