I have a web application that creates a session for every user who logs in and 
also tracks logins/logouts in a database. When the user logs out or when the 
session is destroyed (using a SessionListener), I attempt to update the 
database with the session destruction time. I experience two problems in a 
clustered environment:

1. Shutting down one resin node in the cluster seems to kill the session on 
that server even though the session is transferred to the other resin server 
and remains available. So, in effect, we think users are logged out when they 
are still active on the second server.
2. My database shows that some sessions seem to stay alive for days even though 
there is clearly no activity on the session.

For the first issue, is there a way to write my session listener so that it 
knows the difference between a real session death and a transfer to another 
clustered instance due to a shutdown?

For the second issue, I found an interesting attribute on the "session-config" 
tag (http://www.caucho.com/resin-4.0/admin/clustering-ref.xtp#sessionconfig):
invalidate-after-listener: If true, invalidate the sessions after the session 
listeners have been called

The documentation doesn't specify a default. Is it possible Resin is 
invalidating the session before my listener has a chance to inspect it, thus 
the listener can't update the database because the it doesn't know the user 
information? What is odd is that most of time the database is updated 

Anybody else track user login behavior in a clustered environment? Going to be 
writing a message queue analytics system that could also track this but for now 
direct db is too simple to drop, especially when it works most of the time.

resin-interest mailing list

Reply via email to