Spring 的 WebUtils.getSessionMutex(javax.servlet.http.HttpSession) 和 HttpSessionMutexListener 仍然相关

Question

我想知道 Spring 框架的 HttpSessionMutexListener 监听器是否仍然适用于今天的应用程序服务器/Web 容器(比如 2.5+ servlet 规范服务器，如 Tomcat 6 或 Tomcat 7)以锁定 session 集群环境中的对象(即在不同的 JVM 之间)，还是它们只解决集群环境中 2.3(或以前的)servlet 规范容器的并发问题，现在没有必要了？

Answer 1

我认为您授予了 Spring 的 session 互斥体更多的权力，而不是它应得的。它只是一个以公共(public)名称 WebUtils.SESSION_MUTEX_ATTRIBUTE 存储的 session 属性，旨在用于 synchronized 语句的表达式中。我不太确定它如何用于“在集群环境中锁定 session 对象”。这是 Spring 自己的代码中的一个用法片段:

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

一个 JVM 中对 mutex 对象的引用对另一个 JVM 不可用，因此获取它的锁不会对在另一个 JVM 中运行的代码产生任何影响。但是，servlet 规范确实包含以下内容:

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

此要求至少从 2.3 开始就存在，并且可能导致分布式应用程序表现得好像 Spring 互斥体正在做某事，而实际上，它是容器强制要求一次由一个 JVM 处理。

顺便说一句，这让我想起几年前我在 concurrency-interest 上发表的一篇文章，其中提到了 Spring 的 session 互斥体:

JTaP article on stateful web apps

根据评论更新:

假设 JVM-1 和 JVM-2 组成一个集群中的两个节点。还假设 request-1 和 request-2 参与同一 session 。如果 request-1 正在 JVM-1 中处理，则在 request-1 完成之前，request-2 无法在 JVM-2 中处理。但是，请求 2 可以由 JVM-1 并发处理。

对于在不同 JVM 中处理请求的情况，这意味着由第一个请求 (JVM-1) 引起的任何 session 更改都将对第二个请求 (JVM-2) 可见。