James,
<vendor>
For what it is worth, we often license "pieces" of GemStone/J separately. So
you could probably swing a deal for just PCA and go to town!
And for clarity, we do not currently flush STSB state to PCA, if our sales
literature suggests this, chalk it up to gratuitous marketing! We do
automatically handle this for clustered HTTP session state only at this
time. However it is a simple manner to store session state in PCA and index
it by a key ( stashed in a cookie, or hidden field, or as an argument to a
stateless bean...).
</vendor>
Don't want to mislead anyone...
-Chris.
> -----Original Message-----
> From: James Cook [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, April 18, 2000 4:05 PM
> To: [EMAIL PROTECTED]
> Subject: Re: HttpSession versus EJB Session Bean
>
> 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".
===========================================================================
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".
