Hi! > One issue is that garbage collection only happens at some random time > after the session is no longer used. So the timeout thread could end up > calling into the ConversationManager even after the session has been > explicitly removed. Possibly the ConversationManager could implement > HttpSessionBindingListener and remove itself from the weak list. Is this > called when a session is deleted? > I think this works only for listeners configured within the web.xml. IF we create such a listener we could invalidate the conversation manager at all (e.g. on unbind) our thread can check this flag then. We can start up and shutdown the thread within this listener then.
> Another is that there could be potential locking issues re someone > accessing a session at the same time that the timeout thread stars > processing the ConversationManager in that same session. > currently the thread synchronize against the conversationManager instance ... should work then too. > And I'm not sure what the implications are with respect to distributed > sessions. Distributed sessions are a pain (for us). The best we can do is to ensure that the conversationManager instance is correctly replicated to another node so that it has no running conversation there. On failover the other node will have no conversation and the user is redirected to the conversation start page. I'd say this is just a short interruption in the workflow - especially since I do not know how JPA at all has some definition how to replicate its session data. > I need to read up on distributed sessions.. > So should I :-) Ciao, Mario
