Why should Tomcat's PersistentValve not be used where there may be concurrent requests per session?

Question

In the class comments at the top of PersistentValve there is a usage constraint:

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

Why is this constraint here? Perusing the code I see three reasons:

1. Concurrent requests for the same session on different Tomcat instances may be subject to "last write wins" and thus potential loss of session data.
2. Concurrent requests for the same session on the same Tomcat instance may result in NPE due to session.recycle() setting the manager to null in the shared session object and another request dereferencing manager when attempting to save the session to the store.
3. Performance inefficiencies (e.g., redundant persistence store access, etc.).

Are there other reasons?

Answer 1

Doing an SVN-Blame I found this comment was added in svn revision 652662 on May 1st 2008 while fixing bug 43343 using the commit comment: Fix bug 43343. Correctly handle the case where a request arrives for a session we are in the middle of persisting..

The context of the bug strongly points at your suggested reason (1) that it is about data loss. In the initial bug description the OP says:

... The only place I saw other issues was inside of: java/org/apache/catalina/valves/PersistentValve.java

where it incorrectly grabs the store from the PersistentManager and uses it directly instead of using the manager API. To me this is bad in that the manager is not able to be the manager and this other logic is accessing the store directly and should never happen...unless it is used only in test cases etc.

So here it is considered the Managers' sole task to use the session Store for storing, loading and deleting sessions. But the PersistentValve does the same too and might easily interfer with what the manager does.

During the bug fix commit beside modifying the PersistentManager, only the comment in question was added to PersistentValve.java plus an unused variable was removed:

- StandardHost host = (StandardHost) getContainer();

While I don't know the purpose of this line removal or past presence, I consider the committer Mark Thomas recognized during code review and patch that PersistentValve can only guarantee constistent session writes when there's only a maximum of one request active per session at any point in time. Else lost writes may occurre.

I won't judge how practical this is, but just thinking about plenty of ressources loaded in parallel per web page impression (main HTML, CSS, JS, Images).

I'm still unsure if this can even be a problem using a single Tomcat instance.