JavaEE Session Listeners

The JavaEE specification defines some listeners that can be used to monitoring the session activity. Specifically there are three of them although one was just created in the last version 7:

• javax.servlet.http.HttpSessionListener: A listener for monitoring session lifecycle (session creation and destruction).
• javax.servlet.http.HttpSessionAttributeListener: A listener for monitoring attribute changes (when an attribute is added, modified or deleted from the session).
• javax.servlet.http.HttpSessionIdListener: A listener for monitoring session id changes, this listener is new in JavaEE 7 and it was created because now it is possible to change the session id programmatically is order to avoid Session fixation attacks.

Since version 0.5.0 those listeners where merely not taken into account (the behavior was not even tested), but since version 0.5.0 the couchbase-manager tries to manage the three listeners mildly. Until now the session inactivity period was the same in the JavaEE server than in couchbase repository. This way the session was valid while it existed in the database. Nevertheless this way of working makes the session unavailable once it was invalidated by inactivity, the session was missing and the attributes cannot be accessed (therefore the listeners worked bad when the session was destroyed by inactivity). Since 0.5.0 the couchbase-manager gives an extra time for the session in couchbase (property extraInactiveInterval, 180 seconds by default). When deleted because of inactivity the session can be read and the attributes accessed, and the listeners are called properly.

Now the listeners work perfectly when only one JavaEE instance is used, but the manager is mainly thought to be used in multi-instanced clustered environment, the behavior when several instances are in placed more complicated (as it is in the majority of implementations) and is the following:

• In sticky configuration the manager works exactly as it was only one instance, each instance manages only their sessions and, in every aspect, it is the same as two single instances. So in this configuration the listeners are properly called.

• In non-sticky configuration things are quite different, the session is managed by both instances and the listeners calls are delivered by both instances. The session is created in only one instance (the other server finds the session in the couchbase repository so it is not created again) and the different attribute and session id change are called in the server the operation happens (so this calls are only delivered to the listener in the server they happen, never to the listener in the other instance). Finally the destruction is the most weird event, the listener is called immediately in the server the session is destroyed, but, in the other server the instance is still active, and the listener was called when the inactivity timeout is triggered. But, even weirder, when the listener is triggered the session was deleted in couchbase so no information about attributes is in place.