Hi,
In my case I'm using Servlets to access the Session beans. I plan to use
Clustered Environment using WebLogic. Right now I'm storing all the data
that needs to maintained across sessions in the HttpSession object. Will
this work in a clustered environment.Will the subsequent http request go to
a Servlet which gets the same HttpSesson object? If not, How do I need to
change it?
Even if I store the state variables in a stateful session bean, ultimately
the handle to the session bean will be stored in the HttpSession object.
Any pointers?
Regards,
Parikshit
----- Original Message -----
From: Aravind Naidu <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, June 06, 2000 9:59 AM
Subject: Re: Servlet sessions vs statefull session beans
> 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".
===========================================================================
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".
