Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <390DB47C.FC0BC7EB@eng.sun.com>
Date: Mon, 01 May 2000 09:44:44 -0700
From: "Craig R. McClanahan" <Craig.McClanahan@eng.sun.com>
MIME-Version: 1.0
To: tomcat-dev@jakarta.apache.org
Subject: Re: [Catalina] Session Store?
References: <390CD738.E95CF71A@chrispy.net> <390CE89A.CD81554C@eng.sun.com>
 <390DB220.EDBC4BB9@algroup.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ben Laurie wrote:

> "Craig R. McClanahan" wrote:
> >
> > Hi Chris .. I'll be happy to sign you up for whichever Store implementations you
> > want to work on.  You're correct -- the FileStore one needs to be fleshed out
> > (although I'm not sure that file-per-session is going to scale real well).  I'd
> > also like to see Store implementations that use a database via JDBC, plus other
> > approaches that might sound reasonable.
>
> Like Splash (the distributed store I was bending your ear about at
> ApacheCon - now working in prototype) ... tell me - I've never actually
> looked inside a Java session store - how big do they get? I realise this
> is a "how long is a piece of string" question, I'm just trying to get a
> feel for rough figures for typical applications.
>

The only rational answer, of course, is "it depends ..."  :-)

I view session stores as being useful in (at least) the following broad categories:

* Large web application with lots of relatively long-lived sessions, but
  many of them not currently active (and therefore it becomes
  possible to swap them out).  This lets you run an app where not all
  the active users can fit in the memory of your server, in the same way
  that an OS lets you run apps whose total memory requirements exceeds
  the physical memory of the server.

* Mechanism to share session information in a load balanced environment
  (the Store interface probably needs to be beefed up to deal with this)
  similar to what you were talking about.  This subdivides into situations
  where a session sticks to the first server that it is assigned to (like Apache
  JServ does it today) and situations where a session can be migrated
  between servers for load balancing or failure recovery.

* Mechanism to save session state across server restarts (either
  normal shutdowns or auto-reloads during development).  Performance
  is probably not as big a concern here.

So the answer is ... maybe thousands of sessions, with data content of the type
typically stored (i.e. serializable objects representing the current application
state).  I suspect many apps will run into other bottlenecks (like database or network
performance) before they hit constraints due to the Store implementation.

>
> Cheers,
>
> Ben.
>

Craig McClanahan