Я думаю, вы даете больше энергии сеансовому мьютексу, чем оно того заслуживает. Это просто атрибут сеанса, хранящийся под открытым именем WebUtils.SESSION_MUTEX_ATTRIBUTE, который предназначен для использования в выражении для оператора synchronized. Я не совсем уверен, как его можно использовать для «блокировки объекта сеанса в кластерных средах». Вот фрагмент использования из собственного кода Spring:
HttpSession session = request.getSession(false);
if (session != null) {
Object mutex = WebUtils.getSessionMutex(session);
synchronized (mutex) {
return handleRequestInternal(request, response);
}
}
Ссылка на объект mutex в одной JVM не будет доступна для другой JVM, поэтому получение ее блокировки не повлияет на код, выполняемый в другой JVM. Однако спецификация сервлета содержит следующее:
В приложении, помеченном как распространяемое, все запросы, которые
часть сеанса должна обрабатываться одной JVM за раз.
Это требование существует по крайней мере начиная с версии 2.3 и может привести к тому, что распределенное приложение будет вести себя так, как если бы мьютекс Spring что-то делал, хотя фактически это контейнер, который принудительно обрабатывает запросы одной JVM одновременно. 1013 *
Кроме того, это напоминает мне о посте, который я сделал для интереса параллелизма несколько лет назад и который ссылается на мьютекс сеанса Spring:
Статья JTaP о веб-приложениях с отслеживанием состояния
Обновление на основе комментария:
Предположим, что JVM-1 и JVM-2 составляют два узла в кластере. Также предположим, что request-1 и request-2 участвуют в одном сеансе. Если запрос-1 обрабатывается в JVM-1, то запрос-2 не может быть обработан в JVM-2, пока запрос-1 не будет выполнен. Однако запрос-2 может обрабатываться одновременно JVM-1.
Для случая, когда запросы обрабатываются в разных JVM, подразумевается, что любые изменения сеанса, вызванные первым запросом (JVM-1), будут видны второму запросу (JVM-2).