tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
Date Thu, 08 Sep 2005 21:31:32 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=36541>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36541





------- Additional Comments From jason@kumachan.net.nz  2005-09-08 23:31 -------
Looks like the problem will hard to reproduce as it requires a situation where a
write to the hashmap causes a table resize/reindex to occur while another thread
is reading from the hashmap.

I would have thought it would return a null when it couldn't find the value. 
But there is no guarantee on what happens.

Developers could sync on the session everytime they want to read.  But why
should they, it is adding to the complexity of writing web apps.  As Wade
Chandler points out it may not even be possible with the JSTL tags.

Some have suggested using ReadWriteLock or some other tricky method of reading,
checking if null, and then doing a synced read.  Which is all very good, but
there is a simpler solution (for tomcat 5.5) - use ConcurrentHashMap - it says
that "Special-purpose data structures such as the Concurrent hash tables in this
package have far less overhead, and typically much better performance than
placing ReadWriteLocks around most sequential data structures."  Also, the
ConcurrentHashMap already does the second suggestion of doing a sync after a
null is returned (if you look at the link at the end of this).

Here you have someone who has done all this hard work of figuring out when you
can read/write and deals with locking.  It will give you consistant results, and
takes out the opportunity for developers to make mistakes themselves with
deciding whether to sync when reading from a session or not.  Plus JSTL and
everywhere else will benefit in not getting inconsistant results.

Next stop, Application scope...

some more reading about ConcurrentHashMap internals:
http://www-128.ibm.com/developerworks/java/library/j-jtp08223/

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message