Hi,
Also are we creating the inability to meet future client needs (maybe a Java
application) with storing the state in the servlet or would people propose
that the new Java application go through the servlet to access the ejb
server. Maybe I am reading things all wrong time to go home.
William
> -----Original Message-----
> From: Louth, William (Exchange)
> Sent: Tuesday, April 18, 2000 9:38 PM
> To: 'A mailing list for Enterprise JavaBeans development'
> Subject: RE: HttpSession versus EJB Session Bean
>
> James I think Inprise does offer the ability to have the state stored to
> Sysbase or Oracle if I read the following correctly:
>
> <ias-faq>
>
> http://www.inprise.com/devsupport/appserver/faq/Availability_Scalability_P
> erformance.html
>
> * What happens if VM 3 crashes?
> Your shopping cart will be unavailable until the Session Storage service
> is brought back up. Once the service is back up, you are back to where you
> were before VM 3 crashed. This is really the same issue that you would
> have if any database failed. Note, however, that since the Session Storage
> API is IDL, it is possible for you to write your own highly-available
> service, possibly built on Oracle, or something extremely robust. That
> being said, note that it is in fact less likely that VM 3 crash, than
> either VM 1 or VM 2, because VM 3 is not running user code. VM 1 and VM 2
> are both running Containers with user-code in it. VM 3 is only running
> JDatastore and the ORB, which both tend to be quite stable, as far as Java
> code is concerned.
>
> </ias-faq>
>
> I feel uncomfortable putting the state in the web tier and intend to look
> more into this aspect and what are the consequences. Has the gemstone site
> got something a bit meatier than the typical marketing stuff on their
> proposed solution. I also think there is others ways to address the
> problem and possibly compliment the solutions viewing it from the hardware
> perspective and software (AppCenter 4.0 & OAD - it is CORBA).
>
> Putting all this aside do people not feel that the stateful session bean
> is more akin to OO and EJB than servlets with state.
>
> kind regards,
>
> William Louth
>
> -----Original Message-----
> From: James Cook [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, April 18, 2000 9: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".
***********************************************************************
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".
