My understanding is that in Weblogic cluster once the
initial request creates the initial session all
subsequent requests will get that session because the
request will be redirect to the appropriate server
instance. It makes no sense otherwise.
--tinou
--- Parikshit <[EMAIL PROTECTED]> wrote:
> 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".
>
__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com
===========================================================================
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".
