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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
