-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chuck,
On 3/2/2009 1:54 PM, Caldarale, Charles R wrote: >> From: Karl San Gabriel [mailto:karl.sangabr...@gmail.com] >> 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 org.apache.catalina.session.StandardSessionFacade. 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 attributes. 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmsVY8ACgkQ9CaO5/Lv0PCy0QCglTwRqoLZASK51zDLJ49iBcWN hTEAoLB5TfQcqX5/sBSS9duKQ+ipe6yJ =zJiq -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
