tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: session.isNew() not thread safe?
Date Mon, 02 Mar 2009 21:54:23 GMT
Hash: SHA1


On 3/2/2009 1:54 PM, Caldarale, Charles R wrote:
>> From: Karl San Gabriel []
>> Subject: Re: Re: session.isNew() not thread safe?
>> Session object is not thread-safe.
> Please don't post false information - do your homework. To quote from
> 7.7.1 of the servlet spec:
> "Multiple servlets executing request threads may have active access
> to the same session object at the same time. The container must ensure that
> manipulation of internal data structures representing the session
> attributes is performed in a thread safe manner."

Interestingly enough, the specification doesn't say that the session
object itself is threadsafe. It just says that the internal structure of
the object has to remain sane under threaded conditions.

That sounds like a stupid distinction, but consider this:

1. setAttribute and getAttribute must certainly be threadsafe (that is,
multiple threads doing get/sets on the attribute hash won't corrupt each
other). Otherwise, webapps would fail all the time.

2. The object returned by Tomcat for a call to
HttpServletRequest.getSession() is a

3. StandardSession.getSession() is unsynchronized and creates instances
of StandardSessionFascade wrapping 'this' and stores them in a member.

Thus, you cannot guarantee that using the session object itself for
synchronization (like doing "synchronized(session) { ... }" in your code
will give you exclusive access to your session object. I'm not entirely
convinced this exclusive access is necessary, since mostly people are
doing set/get attribute calls and those will be fine.

But, if you wanted exclusive access to the session (say, to increment
the number of requests handled by the session and store that variable in
the session), I don't believe there is a way to ensure that the count is
correct. There is always a race condition because the session itself
cannot be used as a monitor.

You can't even throw an object into the session to be used as a monitor
because you'll have to check to make sure the monitor object is null,
then shove one into the session, and you can't guarantee that all
threads will see the null and then use the new object in the session

Of course, all this is pretty much academic, since once the
StandardSessionFacade object has been created (or you stick a monitor
object in the session attributes), everything is fine after that.

But the point is that you can't just say "synchronized(mySession) { ...
}" and expect no surprises at all.

- -chris
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message