Re: Maintaining Session in Application Server

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".