Hi, 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
