tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Wong" <>
Subject Re: Distributed Session Server
Date Wed, 28 Jun 2000 17:04:28 GMT
I totally agree that having the ability to separate out the dedicated 
session server would make the product more robust and marketable too. If 
this could be done efficiently. that is a great idea and great solution to 
many business. :) for me too

>From: "Matthew Dornquast" <>
>To: <>
>Subject: Re: Distributed Session Server
>Date: Wed, 28 Jun 2000 13:46:42 -0500
>RE>"IMHO the application have to deal ( and accept ) the possibility of
>I agree 100%, I don't want to avoid the issue, I want to better isolate our
>services in order to provide increased flexibility and uptime.  (And 
>*** Imagine this environment:
>A web application that has a 99.9% production uptime requirement and is
>distributed across 10 web servers, 10 tomcats, 2 very reliable application
>servers and one very reliable database.
>The webservers have a redirector in front of them that reroutes http
>requests to provide load balancing and auto recovery of failed http
>requests.  The application server is distributed, and database has a 5
>minute hot spare in standby.
>Now for various configuration/production reasons, we need to restart 
>Because session information is localized in the container, session state is
>*** One possible solution
>Okay now this gets subjective, and I'm really interested if you think this
>doesn't make sense:
>Move the session storage out of tomcat and into dedicated session 
>These servers sole purpose is to provide services that:
>a)store session info
>b)retrieve session info
>c)distribute info amongst the collective farm of session servers.
>d)migration of data from ram to persistent offline storage after certain
>period of time.  (Nice to have, not critical)
>In doing so I think I'll gain:
>a)increased flexibility in maintaining front end web sites.
>b)more transparent recovery if a web server/tomcat instance fails.
>*** Kudos:
>Obviously there is a cost when moving session storage "out of process" from
>the tomcat vm perspective.  But I think if done correctly, it will come
>close to mirroring the performance impact of sticky sessions, thus it'd be 
>And as I said, I really like the default sticky session architecture.  I
>think it solves 99.9% of the session storage requirements that are out 
>today in a very elegant way.  I imagine the session server could be "drop
>in" addition, similar to jikes for jsp.
>PS> So the final env would be something like this:
>2 redirectors
>10 webservers with tomcat, configured in server.xml to use primary and
>secondary session servers
>2 session servers (primary, secondary)
>1 application server
>1 database
>----- Original Message -----
>From: <>
>To: <>
>Sent: Tuesday, June 27, 2000 5:20 PM
>Subject: Re: Distributed Session Server
> > > While I like the "sticky session" feature built into tomcat,
> > > it doesn't meet our needs production needs.
> > >
> > > (A tomcat server goes down, all sessions on that server are toast)
> > >
> > > So before I go out and write a distributed fault tolerant session
> > > server for tomcat, is there already one that is started or in 
> >
> > Well, it will not be easy - partial "fault tolerant" may work, but you 
> > never be sure that a session will be preserved.
> >
> > IMHO the application have to deal ( and accept ) the possiblity of
> > failure. Session is a form of data repository/persistence, and I don't
> > know any such a thing that can be 100% fault tolerant.
> >
> > It is better to design your application to deal with storage failures (
> > by using transactions for example ). You just can't avoid that, and all
> > session tricks ( saving in databases or files, sending UDP broadcasts or
> > whatever else ) are just reducing the server performance without giving
> > any real benefit ( since the data can still be lost - and your servlet
> > will still fail because of that if it doesn't handle the error).
> >
> > When somebody finds a way to implement a 100% fault tolerant data
> > repository, probably it would be a big day for databases and we can
> > forget about transaction.
> >
> > Costin
> >
> >
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> >
> >
>To unsubscribe, e-mail:
>For additional commands, e-mail:

Get Your Private, Free E-mail from MSN Hotmail at

View raw message