tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@algroup.co.uk>
Subject Re: [Catalina] Session Store?
Date Mon, 01 May 2000 19:15:33 GMT
"Craig R. McClanahan" wrote:
> 
> 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.

Splash's initial motivation was to solve the second problem, but it
probably would also work for the third (it will have pluggable stores
[yeah, I know, a pluggable store with pluggable stores underneath, blech
- but it is written in C] and they could be persistent. In fact, I'm
likely to add DB soon).

The first is _much_ harder in a distributed environment and I currently
have no intention to address it.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Mime
View raw message