An in-memory servlet session is always faster than a stateful session bean.
And the nice API provided by the servlet spec makes it easy to store all
kinds of stuff inside the session object.
Now, the above scenario is ok for a single machine configuration.
When you are in a cluster and if you want 24x7x365 then you would put a
non-stick affinity clause in your network dispatcher (http sprayer). In this
sort of scenario as a http request can go to any machine in the cluster, you
need persistent sessions.
You then have a couple of options. Ignore the HttpSession object and persist
your state onto a stateful session bean.
The other and better option would be to choose an AppServer that has
persistent session capability.
WebSphere can persist session automatically to the admin database or to an
EJB with the flick of a switch, no programming required. Gemstone aparently
has similar ability to persist sessions by using their PCA mechanism.
Don't know about the other vendors.
The general rule of thumb in a distributed system is that - the closer the
state is held to the client, the faster your application.
Why fiddle around with stateful EJB's etc... when an app server can provide
excellent session support for both a single machine scenario and a clustered
scenario. The App server also handles all of the session objects lifecycle,
expiry etc. The big plus is also that you are using a spec'ed API to write
this code and you expect the app server to optimise the access for you.
There is a whitepaper from a vendor recommending that all session state be
stored in a stateful EJB. Upon closer analysis it works out that they don't
support persistent sessions and that was their way out.
It is always nice to have a choice and especially in a clustered env, you
need persistent sessions to get your network architecture optimised.
For me the general rule of thumb is to use the HttpSession object. Then I
can make a late decision to either persist it etc. depending on my network
architecture.
I would go to a stateful EJB only if you need access to session state from
an client other than a Java servlet. Even there, since I am a WebSphere
user, I will use their automatic persistence of the session object to an
EJB, and access this thro' their API from non-servlet clients.
-- Aravind
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jim Archer
> Sent: Tuesday, 6 June 2000 12:38
> To: [EMAIL PROTECTED]
> Subject: Servlet sessions vs statefull session beans
>
>
> Hi All...
>
> I am interested in peoples opinions on the relative advantages and
> disadvantages of servlett sessions and statefull session beans. I
> have read
> many places that statefull session beans are inefficient, since they
> instantiate a bean that lives as long as a client does, and there is one
> per client.
>
> I'm wondering how this overhead compares to useing session data in a
> servlet? Is the servelts mechanism for storing session data more efficient
> than using a statefull session bean? In general, which mechanism do people
> use?
>
> Thanks!
>
> Jim
>
> ==================================================================
> =========
> 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".
>
>
===========================================================================
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".
