Nathaniel Alfred wrote:
I had to comment on this. "Session reources" are clearly not the same thing as the session itself. The implication here is that a servlet must be thread safe and that multiple requests can occur for the same session simultaneously. Any objects that are scoped to the session must be written to support that. It doesn't necessarily imply that synchronizing on the session is OK (which you pretty much came to the conclusion later in the email).
Global synchronization on sessions saves two lock operations and gives better single-threaded performance.
Local synchronization on serverSession/sessions.get/sessions.put gives better multi-threaded concurrency.
Both effects are really minute. I now tend to favour your proposal to use the global lock because is saves a lot of brain cycles during code inspection.
However, I am amazed by your categoric opposition to locking the
serverSession. The whole story started because Joerg wants to use the session object in order to coordinate concurrent requests belonging to the same session. I had a difference of opinion with him as well about
the object identity guarantees in HttpRequest.getSession.
I now read it up in the Servlet specs. Both 2.3 and 2.4 use the same wording in SRV.7.7.1 Threading Issues:
Multiple servlets executing request threads may have active access to a single session object at the same time. The Developer has the responsability for synchronizing access to session resources as appropriate.
That clearly states that synchronized(serverSession) is allowed and must be used when necessary.
Ralph
Ralph
