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.

Until 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 still read and the attributes accessed, therefore 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 place is 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, each instance calls the listeners for the sessions it manages.

• In non-sticky configuration things are quite different, the session is managed by several instances and the listeners calls are delivered by several instances too. The session is created in only one instance (the other servers find the session in the couchbase repository so it is not created again, the listener is not called again) and the different attribute and session id changes 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 any of the other instances). Finally the destruction is the most weird event, the listener is called immediately in the server the session is destroyed, but, in the other servers the session is still active, and the listener will be called when the inactivity timeout was triggered. But, even weirder, when the listener is triggered the session was deleted in couchbase so no information about attributes is in place (the same that happen in previous versions).

In summary, since version 0.5.0 the session listeners are working in the couchbase-manager. In sticky configuration they work normally but in non-sticky there are some special characteristics (as in any other non-sticky implementation). The listeners are only called one time in the server which executes the request (for example if you set an attribute, only the listener in the server which processes this request is called) except the destruction of the session. The session destroyed event is executed as many times as servers managed the session, the first call is the proper one (executed in the server which really destroyed the session) and the other servers destroy it just because of inactivity. So please, if your application manages session listeners you have to carefully think about this behavior in the non-sticky configuration.