I read the article by Salil Deshpande and agree with James Cook's analysis
of it. It is very biased to the fact that Inprise do not handle clustering
at the web tier with the ability to persist the HTTP session object.
What is really worrying is that this bias is taken to be understood as that
storing state in a stateful session bean is the best way to achieve this.
As an application designer, what I expect from my vendor is options. The
more the better. When building a 24x7x365 system, I need the option of
clustering at various levels, web server boxes, servlet engine boxes, ejb
server boxes with the proviso of failover at every level.
The general rule of thumb in storting state in a distributed system, is "The
closer the state is to the client, the better the performance of the
distributed system."
<WebSphere User>
WebSphere allows me to persist the session state to the administration
database, currently DB2 or Oracle. It is a simple switch in the setup to ask
WAS to make the session go from in memory storage (default) to the admin
database.
Thus with WAS, I can do IP balancing/failover with eND (eNetwork
Dispatcher), servlet engine balancing/failover with the redirector, and EJB
server balancing/failover with WLM (Workload Manager).
</WebSphere User>
Thus, depending on what my client is (servlet/application) etc., I do have
the option of storing state anywhere. Sun has designed the HTTPSession
object specifically for this purpose and if your application is made up of
servlets, then use it, with the proviso, that if you need clustering with
failover, your app server vendor supports it.
WAS 3.0 also will support in the near future, transparent storage of the
HTTPSession object as an EJB, for access from other clients other than
servlets, when you have a mixed client system. I always prefer if an app
server vendor does all this for me rather than me having to code it all
myself and I can keep throwing switches around to decide where the storage
of the session object is either in the database or in an EJB, depending on
my application architecture. They will also provide a non-JDBC access to the
session object in the database. Options are great !!!
As James rightly points out, the database becomes the single source of
failure and that is why that database in our system is on a HA cluster.
-- Aravind
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of James Cook
> Sent: Wednesday, 19 April 2000 06:05
> 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".
