Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
From: "James Cook" <jimcook@iname.com>
To: <tomcat-dev@jakarta.apache.org>
Subject: RE: [Catalina] Session Store?
Date: Mon, 1 May 2000 19:46:24 -0400
Message-ID: <NDBBJEEMIKODGFAJCIGMOECACKAA.jimcook@iname.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <390DD7D5.47045B87@algroup.co.uk>
Importance: Normal

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
>
>