Sorry, I was not advocating using JDBC to store persistence. I was telling,
let the AppServer to do it. I really don't care how the AppServer achieves
this as long as it is fast and reliable.
For eg., I think Gemstone uses their PCA method to persist this and
WebSphere uses native DB2 calls to do this.
-- Aravind
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Srinivas Ganapur
> Sent: Saturday, 24 June 2000 16:56
> To: [EMAIL PROTECTED]
> Subject: Re: HTTP Session Vs Stateful Session Beans
>
>
> Hello,
>
> Its good idea to store the state of a client session in stateful session
> bean (SSB) rather than using the JDBC method. The performance is quite
> good using the SSB than using the JDBC persistence in DB.
>
> Has anybody developed a strategy to use SSB in EJB clustered environment.
> This may be possible in application servers which supports state
> management
> across app server. But how to implement it in the EJB app servers which
> doesnt support this.
>
> Thank you,
> Regards.
>
> Ganapur Srinivas.
>
> Cognizant Technology Solutions India Ltd.
> Ground Floor,
> Deepak Complex,
> National Games Road,
> Opp.Pune Golf Course,
> Yerwada.
> Pune 411006.India.
> Tel. :6691960.Extn-2277.
> [EMAIL PROTECTED]
>
>
> -----Original Message-----
> From: Aravind Naidu [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 23, 2000 7:09 PM
> To: [EMAIL PROTECTED]
> Subject: Re: HTTP Session Vs Stateful Session Beans
>
>
> >
> > Ummm, I don't really know what HttpSession data is, but it sounds
> > supiciously like something in a servlet engine. How does this work
> > in a clustered environment in which a user might find themselves on
> > any of the cluster members, and need to have access to their session?
> > I think that's why StatefulSessionBeans (preferably persisted to a
> > database) are useful... does that sound right?
> >
>
> Use Persistent sessions. Some of the Appservers support it. As far as my
> experience with WebSphere goes, the session will be persisted
> between calls
> to the admin database (DB2 or Oracle) or to an stateful EJB. It is just an
> admin switch, no programming involved. The nice thing about this, is that
> you are still using the SUN speced API to store sessions, but
> now, they work
> transparently in a clustered environment, even if you implement a
> non-sticky
> affinity clause in your network dispatcher.
>
> I read that Gemstone also does this. I am sure someone from Gemstone will
> provide the necessary details. I don't have enough experience
> with the other
> app servers to know if they support persistent sessions.
>
> The appservers will take care of the programming and optimising the access
> to the session object in a fast, reliable way, which is the
> entire point of
> using the J2EE architecture : leave all this infrastructure stuff to the
> application server.
>
> -- Aravind
>
> ==================================================================
> =========
> 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".
