On Fri Apr 18 14:16:33 CEST 2008 Christopher Schultz <[EMAIL PROTECTED]> wrote:
Ronald,
Ronald Klop wrote:
> Yes, I know how to work around the problem. But I don't like
> workarounds. All implementations I can think of are very fragile. What
> if somebody stops my Tomcat with kill one day?
Then I don't think that you will have to worry about processing
sessionDestroyed messages ;)
Also, that is a somewhat remote possibility. Finally, marking a user as
logged-out isn't the end of the world. You should only have to handle
common cases, here, right?
> My session isn't destroyed, so I don't understand why the event is thrown.
Yes, the session is destroyed. The problem is that, semantically, you
are thinking that session == app login, which is not true.
-chris
Mmm. But why does the client still have the same session after one node shuts
down. The session doesn't live on one node. It lives as long as the cluster
lives.
I understand the Session object in the JVM is destroyed, but one part of
clustering (for me) is to replicate the Session object, so the
'browser-session' lives on.
There is no way for me to detect if the browser-session expires or if the
Session object expires except by hacking around with ugly if statements and
making the deployement more difficult and fragile.
I think session.destroyed should only be called if the last node of the cluster
shuts down. Or if the session expires by timeout.
But maybe our ideas just don't match. That's fine by me.
Ronald.
