Ha. The classic case. There you go.
You need persistent sessions even when you store the handle of your bean in
the HttpSession object.
I am hoping someone from WebLogic will reply saying that yes, they support
it and so they should.
Well, you have a couple of options if they do not.
You can tell your network dispatcher to follow the sticky affinity clause.
This means that requests origniating from an IP are directed to the same
machine in the cluster. (There are various rules you can implement depending
on how good your network dispatcher is.)
The drawback is that if one box goes down in the cluster, the user will be
forced to log back in again to restablish the session. (Not exactly
24x7x365)
The other drawback is what is called the "AOL proxy" problem and the "IBM
proxy" problem. AOL directs all of it's users thro' a bunch of proxy
servers. So, one or a few boxes in your cluster will handle a bulk of the
load if most of your traffic comes from AOL. IBM being a large company, load
balances it's proxy servers, and thus the same user in the same session of
the browser can come from different IP address.
Depending on how good your Dispatcher is it can handle the above situations
via various means.
Thus, the ideal cluster should not have sticky affinity and you get the best
performance, load balancing and best failover.
-- Aravind
> -----Original Message-----
> From: Parikshit [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, 6 June 2000 14:53
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Re: Servlet sessions vs statefull session beans
>
>
> 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".
