gpt4 book ai didi

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

转载 作者:行者123 更新时间:2023-12-01 11:03:34 24 4
gpt4 key购买 nike

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

最佳答案

我认为您授予了 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) 可见。

关于Spring 的 WebUtils.getSessionMutex(javax.servlet.http.HttpSession) 和 HttpSessionMutexListener 仍然相关,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/8408049/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com