Thanks to all those who replied on my feasibility question (particularly Andy and Will). The responses were varied, from 'not possible at all' through to 'cookies' and onto 'singleton classes' and 'DB accessing'. All very informative, and food for thought - should make for an interesting application design.
Thanks Iain ----- Original Message ----- From: "Will Hartung" <[EMAIL PROTECTED]> To: "Tomcat Users List" <[EMAIL PROTECTED]> Sent: Monday, July 08, 2002 7:05 PM Subject: Re: Feasibility question > To wit he means that with the built-in session management, you pretty much > don't have to do anything. > > It all comes down to how much information you need to share across > applications. > > If you want to store the stuff in memory, then the Singleton class in the > system classpath mentioned previously will work fine, otherwise you need to > persist it to something (DB typically). The only major detail to this is > that you can't change the Singleton class without restart Tomcat, but > they're usually pretty simple and locked down fairly early in the design > process to where this is usually not a problem. > > If the amount of info is small, it can all be stored in a cookie or on the > URL. > > If it's simply a single sign-on token, then a cookie would be your best bet. > > The biggest detail with the session management is cleaning up afterwards. > You'll need some mechanism that dumps the sessions after they have expired. > This is something that comes "free" with the built-in session management, > but, of course, only works for a single webapp. > > If you're persisting the session info to a DB, then you'll need some kind of > process that sweeps through the sessions and deletes the expired ones. > There's no reason to get overly complicated about it, it can easily be > integrated in the routine that creates a session for a new connection. You > can either just go brute force and delete all of the session info for > expired sessions every time (this will cost roudtrips to the DB, but odds > are pretty good they won't be doing much when they get there), or you can > use a singleton base counter and run the sweep, say, every 100 connections, > or whatever. > > Or you can give a rip, "disk is cheap", and run a simple process once a > hour/day/week/month. All depends on your load. > > For an in memory singleton based manager, you could basically throw all of > the sessions onto a FIFO queue. Everytime the session is accessed, it gets > moved back to the head of the queue. Then, your periodic sweeper can simply > start at the tail of the queue (all of the oldest sessions) and compare > timestamps until you've reached your time out limit. All of those sessions > that have expired are tossed aside for the GC to deal with. > > Regards, > > Will Hartung > ([EMAIL PROTECTED]) > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
