I don't want to take anything away from Gemstone, Inprise or Salil, but the
document in question:
Clustering: Transparent Replication, Load Balancing, and Failover
by Salil Deshpande
http://www.inprise.com/appserver/papers/11501_clustering.pdf
suffers from a little bias and subjectivity.
The main point that I was interested in was the stateful failover,
particularly stateful session beans. Typically, distributed developers are
interested in HTTP session failover and SFSB failover.
HTTP Session Failover
=====================
Salil documents that Inprise does not recommend using the HTTP session
mechanism, but rather defer all session management to Stateful Session
Beans. This is a convenient move since Inprise currently distributes a
modified version of Java Web Server and has no support for clustered HTTP
session.
Gemstone, on the other hand, supports clustered HTTP sessions through the
use of a replication pattern. They leverage their Persistant Cache
Architecture (PCA) to store session state information.
Stateful Session Bean Failover
==============================
The Salil/Inprise article goes on to state that SFSB failover is achieved
through the use of a persistent datastore that periodically is responsible
for passivating the bean's state. All application servers in the farm will
use this datastore for saving state. I find this to be Salil's most
hypocritical statement, especially when compared to his previous statements
that admonish any approach that introduces a single point of failure.
Inprise's use of a single datastore as a means to support SFSB failover is
ripe for potential failure.
I can't talk from experience, and I am always highly skeptical of marketing
fluff, but according to their docs, Gemstone uses their persistent cache to
store stateful session bean state.
Summary
=======
I tried to stay away from bashing either vendor on the concept of failover,
except where it is painfully obvious that a design flaw exists ;-) Any time
you are serializing state across VM boundaries you will take a performance
hit. I don't have any first hand experience with Gemstone's persistent cache
architecture, but I would expect it to react to scalability in an
exponential manner. The more nodes I add to the PCA, the more serialization
necessary to keep these in sync. I am assuming their is a good balance to be
found between failover and performance.
I have found the Inprise approach to be fast (their all-Java JDataStore
matches or beats our Sybase performance). However, it can hardly be
considered to be a failover mechanism. I like the approach of saving state
to a single datastore, however I would like it to be JDBC-based and
flexible. If I can route all session state to Sybase or Oracle, that would
be a better option. Most companies spend a great deal of time and money to
make sure their database access is highly optimized and always up.
BTW, Gemstone should offer their persistent cache as a separate product and
slap a JDBC driver on it! If my customer really wanted performance, I would
have to seriously consider TimesTen. It doesn't get any faster than that!
(http://www.timesten.com/products/timesten/index.html)
jim
----- Original Message -----
From: Randy Stafford <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, April 18, 2000 12:34 PM
Subject: Re: HttpSession versus EJB Session Bean
> 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".
>
>
===========================================================================
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".
