|Summary:||HttpSession access is not synchronized and is causing bugs. Affects all tag libs accessing HttpSession in any way through any means i.e. JSP PageContext|
|Product:||Taglibs||Reporter:||Wade Chandler <hwadechandler-apache>|
|Component:||Unknown Taglib||Assignee:||Tomcat Developers Mailing List <dev>|
Description Wade Chandler 2005-09-10 00:09:02 UTC
HttpSession access is not being synchronized. Please understand that any time the HttpSession is accessed there is no guarentee if the underlying system will protect the data. Other Servlet and J2EE servers other than Tomcat may behave this way. Please see the bug http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 for more details. getAttribute in Tomcat is not synchronizing the underlying HashMap and this can cause more than one issue. Ones noted: 1) A validly set session variable might not get retrieved on a call to getAttribute if a setAttribute occurs on the same session from another Thread, JSP page, or Servlet. 2) Infinite loops have been reported 3) It makes the software unpredictable
Comment 1 Wade Chandler 2005-09-10 00:09:40 UTC
Tomcat however happens to have other code within itself which is not synchronizing access to the HttpSession. Bug reports will have to be filed for all instances. Any help in locating them and filing them is welcome.
Comment 2 Wade Chandler 2005-09-10 00:18:30 UTC
removeAttribute needs to be synchronized as well. Basically ANY HttpSession access should be synchronized as there is no guarentee that access will ever be synchronized for sessions.
Comment 3 Wade Chandler 2005-09-13 17:46:00 UTC
Corresponded with Yoav Shapira from the Tomcat project and he agreed no contract exists that the session is synchronized by the container. Tomcat itself will be synchronized at the lower levels, but that does not mean this will remain true in future versions, nor does it mean this can be assumed for any other container.
Comment 4 Rahul Akolkar 2005-09-24 18:17:20 UTC
BZ#36541 has the tedious details, which indicates that the next servlet spec will clarify this much better so its fixed at the level of all containers. IMO, fixing this in all taglibs is a non-trivial task that will be redundent over time (because when the containers fix this, it will remain as cruft, possibly eating away cycles). Having said that, if anyone wishes to do the work in providing patches for one or more of the taglibs to ensure threadsafe session accesses, please re-open and provide the patch(es). In that case, it would be nice if, when the world moves to the next servlet spec (which arguably may take a while), someone also remembers to take those bits out.