Почему Tomcat PersistentValve не следует использовать там, где могут быть одновременные запросы на сеанс?

Question

В комментариях класса вверху PersistentValve есть ограничение использования:

/**
...
 * <b>USAGE CONSTRAINT</b>: To work correctly it assumes only one request exists
 *                              per session at any one time.
...
 */

Почему это ограничение здесь? Просматривая код, я вижу три причины:

1. Одновременные запросы на один и тот же сеанс в разных экземплярах Tomcat могут подвергаться "последним победам при записи" и, таким образом, потенциальной потере данных сеанса.
2. Одновременные запросы для одного и того же сеанса в одном и том же экземпляре Tomcat могут привести к NPE из-за session.recycle() установки для диспетчера значения null в объект общего сеанса и другого менеджера разыменования запросов когда пытается сохранить сеанс в хранилище .
3. Неэффективность производительности (например, избыточный доступ к хранилищу и т. Д.).

Есть ли другие причины?

Answer 1

Делая SVN-Blame, я обнаружил, что этот комментарий был добавлен в svn revision 652662 1 мая 2008 г., в то время как исправляет ошибку 43343 с помощью комментария коммита: Исправляет ошибку 43343. Правильно обрабатывайте случай, когда запрос приходит на сеанс, мы находимся в процессе сохранения. .

Контекст ошибки настоятельно указывает на предложенную вами причину (1), что речь идет о потере данных. В первоначальном описании ошибки ОП говорит:

... Единственное место, где я видел другие проблемы, было внутри: Java / орг / апач / Catalina / клапаны / PersistentValve.java

, где он неправильно получает хранилище из PersistentManager и использует его напрямую вместо использования менеджера API. Для меня это плохо в том, что менеджер не может быть менеджером, и эта другая логика напрямую обращается в магазин и никогда не должно происходить ... если только используется только в тестовых случаях и т. д.

Так что здесь считается единственной задачей Managers использование сеанса Store для хранения, загрузки и удаления сеансов. Но PersistentValve делает то же самое и может легко помешать тому, что делает менеджер.

Во время фиксации исправления ошибки, кроме изменения PersistentManager, к PersistentValve.java был добавлен только рассматриваемый комментарий, плюс неиспользуемая переменная была удалена:

- StandardHost host = (StandardHost) getContainer();

Хотя я не знаю цели удаления или присутствия этой строки в прошлом, я считаю, что коммиттер Марк Томас узнал во время проверки кода и исправления, что PersistentValve может гарантировать постоянную запись сеанса только тогда, когда в сеансе активен максимум один запрос. в любой момент времени. Иначе могут произойти потерянные записи.

Я не буду судить, насколько это практично, но просто думаю о множестве ресурсов, загружаемых параллельно для каждого показа веб-страницы (основной HTML, CSS, JS, изображения).

Я все еще не уверен, может ли это быть проблемой при использовании одного экземпляра Tomcat.