How to get intimated and catch user sessions when tomcat goes down using struts?

[san jan]

How to get intimated and catch user sessions when tomcat goes down using struts?How to invalidate sessions when Tomcat goes down?
Am using struts. Am using sockets in our application. And session ids are getting saved across tomcat restarts. So sockets are not getting cleaned properly when the server goes down since the session is not getting expired/invalidated.
Thanks,
Santosh

[David O'Meara]

Please don't post the same question in multiple forums. It creates duplicate conversations and wastes the time of the people who are trying to help you
The duplicate is here, but this is a better place for the question. I'll ask for that thread to be closed so that the conversation can continue here.
Dave.

[san jan]

Thanks, that would be great. actually i dint know where to post it.

[David O'Meara]

From the other thread:

David O'Meara:
I'm not sure I understand the question (I fail to see where sockets come into the picture), but you should be able to provide a solution using tokens.
I haven't done enough Struts work, but doesn't it have built-in support for tokens to prevent users submitting the same form twice? Although the sesison ID remains the same, the session data is lost between restarts and therefore the token check would fail.
Just an idea.

san jan:
Probably the way I questioned was wrong.
I am using sockets and they are cleaned up by a method that gets called when a session is found to be invalid. But with tomcat even after restart the session is not becoming invalid (as cookies are used and the server was started before session timeout), but the socket is dangling since the application was closed and restarted.
So I wanted to get intimated before the server goes down so that I can clean the sockets.

OK, let's continue....

[David O'Meara]

intimated == notified??
So what I understand is this:
A user visits your site and is given a session. When they are given the session, the session id is also associated with a socket that is opened to.... somewhere else. Each time they visit, the socket is used for... something. When the session expires, you want the socket to be closed, but this fails when Tomcat crashes.
If it's possible in your solution, I'd use a socket pool (like a database pool) rather than associating a single socket with a single session. That's where the problem appears to be. I know this isn't your question, but I have a large problem with maintaining an open socket mapped to a session id.
Dave

[san jan]

yes infact thats what we had provided before. But our client doesnot want us to use socket pooling, so we had to revert back to this way.
I had tried to catch in destroy() method and also by using listeners, but nothing helps. The problem is that we are storing the socket information as a session attribute as it is per user session as you had correctly understood, and before we can close the socket in either destroy() or in listeners sessionDestroyed() methods, the session attributes are already lost.