Spring's WebUtils.getSessionMutex(javax.servlet.http.HttpSession) and HttpSessionMutexListener still relevant

Question

I'd like to know if the Spring framework's HttpSessionMutexListener listener is still relevant in today's application servers/web containers (say 2.5+ servlet spec servers like Tomcat 6 or Tomcat 7) for locking the session object in clustered environments (ie. among different JVMs), or do they only resolve the concurrency issue in clustered environments for 2.3 (or previous) servlet spec containers and now it is unnecessary?

Answer 1

I think you're granting more power to Spring's session mutex than it deserves. It's simply a session attribute stored under a public name, WebUtils.SESSION_MUTEX_ATTRIBUTE, that's intended to be used in the expression for the synchronized statement. I'm not really sure how it could be used for "locking the session object in clustered environments". Here's a usage snippet from Spring's own code:

HttpSession session = request.getSession(false);
if (session != null) {
    Object mutex = WebUtils.getSessionMutex(session);
    synchronized (mutex) {
        return handleRequestInternal(request, response);
    }
}

A reference to the mutex object in one JVM will not be available to another JVM, so acquiring its lock will not have any impact on code running in another JVM. However, the servlet spec does contain the following:

Within an application marked as distributable, all requests that are part of a session must be handled by one JVM at a time.

This requirement has been around since at least 2.3 and may cause a distributed app to behave as if the Spring mutex were doing something when, in fact, it's the container that is forcing requests to be handled by one JVM at time.

As an aside, this reminds me of a post I made to concurrency-interest a few years back that refers to Spring's session mutex:

JTaP article on stateful web apps

Update based on comment:

Assume that JVM-1 and JVM-2 make up two nodes in a cluster. Also assume that request-1 and request-2 participate in the same session. If request-1 is being handled in JVM-1, then request-2 cannot be handled in JVM-2 until request-1 has completed. However, request-2 can be handled concurrently by JVM-1.

For the case where the requests are handled in different JVMs, the implication is that any session changes caused by the first request (JVM-1) will be visible to the second request (JVM-2).