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

Question

I would like to know if the Spring framework HttpSessionMutexListener receiver remains relevant on today's application servers / web containers (say 2.5+ servlet servlet servers such as Tomcat 6 or Tomcat 7) to lock the session object in the cluster (i.e. among different JVMs) or do they solve the concurrency problem in clustered environments for 2.3 (or previous) servlet specification containers, and now is this optional?

Answer 1

I think you give more authority to the Spring session mutex than it deserves. This is simply a session attribute, stored under the public name, WebUtils.SESSION_MUTEX_ATTRIBUTE , which is intended to be used in an expression for a synchronized statement. I'm not sure how it can be used to "lock the session object in clustered environments." Here is a snippet using native code from Spring:

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

A reference to a mutex object in one JVM will not be accessible to another JVM, so getting it locked will not have any effect on code running in another JVM. However, the servlet specification contains the following:

In an application marked as redistributable, all requests that part of the session must process one JVM at a time.

This requirement has existed since about 2.3 and may cause the distributed application to behave as if mutex Spring is doing something when it is actually a container that forces requests to be processed by one JVM at a time.

As an aside, this reminds me of the message I made for the concurrency interest a few years ago that refers to the Spring session mutex:

JTaP article on stateful web applications

Comment based update:

Suppose JVM-1 and JVM-2 are two nodes in a cluster. Also suppose request-1 and request-2 are in the same session. If request-1 is processed in JVM-1, request-2 cannot be processed in JVM-2 until request-1 is completed. However, request-2 can be processed simultaneously by JVM-1.

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