William Louth wrote:
> I think this document will explain why its better to use stateful session
> beans than servlets holding state. Servlets can be used simply as a
> conduit
> for bringing a client's invocation into the EJB container. All session
> state
> management takes place in stateful session beans.
>
> http://www.inprise.com/appserver/papers/11501_clustering.pdf
>
[Randy Stafford] This document presents a very cogent argument for
why it is better to store session state in stateful session beans than in
HttpSessions, UNDER CERTAIN ASSUMPTIONS that apply to most application
servers on the market, but NOT to GemStone. The argumentation goes
something like this: i) you have to load balance across an array of web
servers / servlet engines to achieve scalability - no argument from me on
that point; ii) in general you don't know which servlet engine will service
the next request in a given conversation, therefore you have to have a way
of sharing that conversation's state between servlet engines - no argument;
iii) if you use a centralized "session state manager" it will become a
bottleneck, and if you replicate all session state between all servlet
engines performance will suffer - no argument; and iv) some applications
need session state to be made durable (in the ACID sense) at certain points
in the interaction, in order to be able to recover the state in case of
failure - no argument, again.
Therefore the document's author recommends that all state be stored
in stateful session beans, and that the reference to the stateful session
bean(s) serving a given conversation be stringified and stored as cookies in
the web browser at the other end of the conversation (thereby eliminating
any need for HttpSessions at all) - note that this requires CORBA under the
EJB implementation, which Inprise provides, and so does GemStone (in fact,
contrary to other vendors' claims, GemStone was first to market with this
capability, having introduced it in 3Q98). The consequence of this design
recommendation, unfortunately, is that the application server / EJB
container must manage a stateful session bean for every concurrent
conversation, which places a heavy demand on server resources in a
high-scale scenario.
GemStone, meanwhile, has features that other application servers do
not have. One such feature, called Persistent Cache Architecture (PCA), is
the full-blown object-oriented database management system capability that
GemStone has been shipping and optimizing since 1987, on which many
high-throughput production systems have run over the years. Another such
feature, called Distributed HTTP Session Tracking (DHST), leverages PCA to
share HTTP session state between servlet engines. Under DHST, each servlet
engine accesses the HttpSession and associated sub-objects for a given
conversation from the object database, and therefore session state is made
durable (in the ACID sense) as frequently as you like. DHST is not a
bottleneck because it leverages the highly-optimized PCA architecture, and
there is no O/R mapping of the objects that comprise session state. As an
example of high scale usage of DHST, one of our customers vends systems
based on it to large universities that run on-line campus communities. And
of course with DHST you don't have to resort to using stateful session
beans, so you can escpae that demand on server resources and serve the same
client load with a much smaller number of stateless session beans.
Best Regards,
Randy Stafford
Senior Architect
GemStone Professional Services
> > -----Original Message-----
> > From: Dave Ford [SMTP:[EMAIL PROTECTED]]
> > Sent: Tuesday, April 18, 2000 12:16 PM
> > To: [EMAIL PROTECTED]
> > Subject: HttpSession versus EJB Session Bean
> >
> > When using ejbs with servlets (or jsp pages), do you typically store any
> > client state in the HttpSession object or do you store all state in a
> > session ejb? What I have been doing is merly storing remote references
> to
> > ejbs in the HttpSession object, then storing all state in the ejb. Is
> that
> > standard practice when using servlets with ejbs?
> >
> > Dave
> >
> >
> ==========================================================================
> > =
> > 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".
>
>
> ***********************************************************************
> Bear Stearns is not responsible for any recommendation, solicitation,
> offer or agreement or any information about any transaction, customer
> account or account activity contained in this communication.
> ***********************************************************************
>
> ==========================================================================
> =
> 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".
