-------- Forwarded Message -------- From: simon <[EMAIL PROTECTED]> To: MyFaces Development <[email protected]> Subject: Re: [orchestra] conversation timeouts Date: Sat, 18 Aug 2007 18:44:19 +0200
Hi Adam, Thanks for your comments. Yes, "hitchhiking" on other requests would be great - if we could solve the other problems you mention. They seem quite tricky though. Additional problems with using other requests are: * how to ensure that session isn't in use when we are scanning, * how to not scan ConversationManagers that are in sessions that have been deleted but not yet garbage-collected. Thread-based solutions appear to also have these problems though. I'm not quite sure what security problems could occur due to exposing session data. Yes, potentially code executing in the context of one request could access another request, but the code isn't user code, it's stuff that was deliberately shipped as part of that webapp. Maybe now that JVMs are shipping scripting languages that integrate with java, perhaps it is becoming possible for user input to inject script code that the container accidentally executes? Still seems rather unlikely though. Hmmm..or maybe if a serialized object was loaded and then executed, eg an evil database driver retrieved via JNDI? Has something like this ever happened for java before? Sessions are identified by a cookie or url-parameter, yes? And we can get them via HttpSession.getId(). So maybe we could record *those* somewhere, then periodically send a request to a special URL with that id. The servlet engine would then automatically recreate the session ready for the timeout code to run in that session. Things like session synchronization in a filter would then apply nicely to prevent races. And no weak references to worry about. Performance of course will be much worse than the internal scanning approach. I'll have a play with this approach and see what happens.. One thing about storing session ids is that it is probably *also* a security issue, as that would make it easy to do session hijacking - they could be encrypted perhaps? Regards, Simon On Sat, 2007-08-18 at 09:05 -0700, Adam Winer wrote: > Mostly ignorant of orchestra, but: > Could you hitchhike on other requests? On any request, > look through a conversation list, and any that haven't > been accessed within 30 minutes get deleted. > If no requests are coming in, then one really doesn't > care about excessive resource use. :) > > Finding a way to make this strategy work that is > adequate in the face of session failover would be very > tricky, though. OTOH, I don't see the problems as > worse than the Thread-based solution. My biggest > concern with an approach of this sort is security - > accessing one session's information from a different > session seems like setting yourself up for major problems. > > -- Adam > > > (simon wrote) > => > I briefly > > > considered having an app-scope list of weak references to > > > ConversationManagers, with instances adding themselves to this list as > > > they are created but that has a number of difficult problems related to > > > timeout/removal of http sessions.
