tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gal Shachor <shac...@il.ibm.com>
Subject Re: Distributed Session Server
Date Thu, 29 Jun 2000 11:03:35 GMT


Paul Speed wrote (and many also):
> 
> Matthew Dornquast wrote:
> >
> > paul>"Until then, our web applications will just have to be programmed to
> > gracefully eat crow when the  gracefully recover from a fault."
> >
> > There is no magic bullet, a well designed web application must gracefully
> > handle errors.  In my mind, the goal is to isolate session data from the
> > webserver/tomcat processes.  Here is why in greater detail to avoid
> > confusion:
> 
>         Yeah, I ramble, but that was more or less my point.  No matter
> how much work you put into fault recovery there are always going to be
> cases where it breaks.  You have to plan for those cases no matter
> what.
> So that's a piece of work you will never get away from.
> 
>         Minimization of breaks is a balance between bang and buck.
> Sticky sessions provide alot of bang for very little buck.  After
> that, a simple scheme involving serializing your HttpSession to some
> data store will catch most other cases.
> 
>         I agree with Costin, though.  Important data doesn't belong
> in the HttpSession.  In fact, this is what second and third tiers
> are for.  I understand that for small applications housed entirely
> within servlets that it becomes an important issue, but then I would
> argue that the state data isn't very important.
> 

Like most of us I had to invest some time thinking what to do with the 
HttpSession and my conclusion was that (at least for the important data) 
it is merely an in-memory cash that I can use to speed up things.

For example think of a user's cart, it does not change much right?
Saving the 
updates in a database and keeping a cashed copy in-memory is going to
save
both time and $, only problem is that at some point in the future we
*know*
that the server will die and then we will have to recover the persistent
portion of our session from a database (yes a database, I am not going
to use
a session server and end up implementing a new database) + recalculate 
the other session attributes.

The only problem in this approach is detecting the JVM crash (and that
the 
sticky load-balancer jumped to another JVM). There are several ways to 
"detect" this, one way is to have the servlets manage a cookie with the
pid
of the JVM... Another approach that I like more is to use the web server
plugins (assuming that Tomcat works behind a web server with a
redirector).

The web server redirector is the one who manage the load balancing and
it can
detect other JVM recovery (very easily) and send a request attribute
that inform
the servlet developer of the crash.

It does not make our programming any easier, but it saves the
performance relatively
reasonable (no more nonstop hits to the database).

	Gal Shachor

Mime
View raw message