It may not be as easy as it seems. We don't need to preserve only the session ID, but any data that has been put in the session. And I don't think there is a requirement in the specs for the data to be serializable.
So a session that may have been "pushed" into secondary memory, may not, in certain cases, be fully restored or restored at all, save for the session identifier. This may lead to difficult bugs to track if data suddenly seems to "disappear" from sessions. For my part, this is a tough call, I think the better way would be to deny the creation of a new session. Like Craig, I don't think that "kicking out old sessions", is such a good idea, because it would appear to users that the site has an "elastic" timeout. On a crowded server, users may very well start doing "blank" hits just to keep their sessions alive. Now, more hits is not what you need on an already overloaded server :) The best is to log the event: The deny of the creation of a new session. Certainly a site that hits this wall needs to be resized, with either more memory or a new tomcat server in a "load balanced" pool. I don't think there will be a perfect answer. For my part, I think the idea to impose a limit on the number of sessions is very good. What I'm not comfortable with, is what we do once this limit is reached. Whatever we do, it must make "sense" if we place ourselves in the shoes of a user of the server. And if someone had already access to the server (an already established session), she shouldn't see a change of behavior because the server is temporarily seeing a burst of activity. "You were kicked out, because somebody else got in." On Tue, 18 Jun 2002, Michael E. Locasto wrote: > I've done a bit of thinking and came up with a mechanism that might > solve both issues of wasted memory and "lost" users. It involves > persistent storage of "retired" sessions, so if this is actually how > LRUMap or the session Manager works, I apologize. > > Basically, we should mimic a virtual memory type of mechanism. If a session > has not been used in a long time, we can store it out or "retire" it to file > system, dbase, ldap, etc... > > In that way, we get some RAM back and do not "lose" the session. If a > request > for a session that is "retired" comes in (like a page fault), we can > retrieve it from disk. > > Granted, this is more complex, and we face a possible new attack (requests > for retired sessions that are actually very very old or invalid). In > addition, a "session request fault" is not guaranteed to have enough memory > to bring the session back in. > > Thoughts? -- Denis Benoit [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
