Spring的WebUtils.getSessionMutex（javax.servlet.http.HttpSession）和HttpSessionMutexListener仍然相关

本文介绍了Spring的WebUtils.getSessionMutex（javax.servlet.http.HttpSession）和HttpSessionMutexListener仍然相关的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

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

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?

推荐答案

我认为你授予Spring的会话互斥更多的权力，比它应得的。它只是一个存储在公共名称 WebUtils.SESSION_MUTEX_ATTRIBUTE 下的会话属性，用于同步语句。我不太确定如何可以用于锁定会话对象在集群环境。这里是Spring自己的代码的使用代码片段：

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);
    }
}

引用互斥在一个JVM中的对象将不可用于另一个JVM，因此获取其锁定不会对在另一个JVM中运行的代码产生任何影响。但是，servlet规范包含以下内容：

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:

此要求至少已经存在2.3，可能导致分布式应用程序表现得好像Spring互斥体在做事情，事实上，它是一个容器，迫使请求由一个JVM处理时间。

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.

另外，提醒我几年前我对并发感兴趣的一篇文章指的是Spring的会话mutex：

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:

根据评论更新：

假设JVM-1和JVM-2组成集群中的两个节点。还假设请求1和请求2参与同一会话。如果在JVM-1中处理请求-1，则在请求-1完成之前不能在JVM-2中处理请求2。但是，JVM-1可以同时处理request-2

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.

对于在不同的JVM中处理请求的情况，是第一个请求（JVM-1）引起的任何会话更改对第二个请求（JVM-2）都是可见的。

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).

这篇关于Spring的WebUtils.getSessionMutex（javax.servlet.http.HttpSession）和HttpSessionMutexListener仍然相关的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！

jvm