tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark O'Driscoll" <>
Subject Re: How to keep track of sessions
Date Wed, 14 Aug 2002 14:09:47 GMT
This is all very interesting but.........

The sessions are currently persisted or serialized on tomcat exit, fine.

I have a collection of session object references.

If I save the references they will be invalid when tomcat starts up.
If I save (serialize) the objects then I am duplicating what tomcat does.

In either case, it's an arse.

Am I missing something.......

- Mark
----- Original Message -----
From: "Shapira, Yoav" <>
To: "Tomcat Users List" <>
Sent: Wednesday, August 14, 2002 3:05 PM
Subject: RE: How to keep track of sessions

I like this thread as a theoretical discussion, so let's pursue it a bit
more ;)

>Depending on the kind of information you want to
>display it gets at sime point annoying to to copy
>everthing from the session to a store and to remove
>it from the store when the session ends.
>  - More code = more possible error, less perfomance
>  - More memory = less performance

More code, yes.  But I think the SessionInfo-type objects would be
trivial.  The manager would be very easy to write as well.  As they are
simple and completely under your control, you could make the processing
and persistence operations very fast.

Having tried that approach on long-running servers with many users and
delayed session expiration (120min), leading to many SessionInfo objects
that had to be persisted on context shutdown and restored on context
startup, I can safely say that performance was not a problem for us.
Even for thousands of SessionInfo object, the persistence operations
were only a few seconds.  And that's on a fairly small server box, JDK
1.2.2 without much tuning.  (Although it was a custom SAXParser and not
Castor, as I suggested before.  Would've been nice to compare them ;)).

>Even if you do it, the problem of the original poster
>is the same. Now he has a Vector of SessionInfo

I agree.  You have to worry about persistence either way.  However,
persisting your own objects is typically a lot easier than persisting
third party objects such as tomcat's session implementation.

The part that I think makes his use-case very interesting and
non-trivial is the requirement to record (and thus persist) the user's
click-stream.  I'm not sure off the top of my head how that fits into
the SessionInfo object, except maybe as a list of URLs the user visited?
We did not have this requirement in the aforementioned system, and so I
can't speak to it...

I'd be interested to hear from the original poster when a solution is
implemented and tested...

Yoav Shapira
Millennium ChemInformatics


> This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential, proprietary
and/or privileged.  This e-mail is intended only for the individual(s) to
whom it is addressed, and may not be saved, copied, printed, disclosed or
used by anyone else.  If you are not the(an) intended recipient, please
immediately delete this e-mail from your computer system and notify the
sender.  Thank you.


> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message