tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <Craig.McClana...@eng.sun.com>
Subject Re: [Catalina] Session Store?
Date Tue, 02 May 2000 04:53:50 GMT
Thanks James ... I will add your name to the (growing) list of contributors in
file "proposals/catalina/STATUS.html" in the Tomcat source repository.

Craig


James Cook wrote:

> Has anyone thought of using JavaSpaces as a Store implementation? Better
> yet, IBM's TSpaces implementation is an order of magnitude faster.
>
> I tinkered about a year ago with the idea of building a distributed web
> server using this approach. Http requests would be put into the tuple space
> and withdrawn by whatever web server was free to do so. It worked quite
> well, however the cost of serializing http requests (responses) was pretty
> abusive on the design.
>
> Regardless, I wanted to implement the session storage mechanism this way as
> well. It seems ideal for those systems that need some sort of failover
> mechanism for session state as well as the immediate benefit of session
> sharing. IBM's TSpace product also can be backed to a database for
> persistence. The only problem lies in their licensing. It is not opensource.
>
> JavaSpaces is a much, much slower implementation with nary half the
> features, but since it is open, it would probably be a better alternative
> for distribution examples. I would be happy to sign up for the
> implementation.
>
> jim
>
> > -----Original Message-----
> > From: Ben Laurie [mailto:ben@algroup.co.uk]
> > Sent: Monday, May 01, 2000 3:16 PM
> > To: tomcat-dev@jakarta.apache.org
> > Subject: Re: [Catalina] Session Store?
> >
> >
> > "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
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message