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 23:03:45 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 hwadechandler-apache@yahoo.com  2005-09-09 01:03 -------
(In reply to comment #56)
> 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.
> 
It should return a null when you simply look at it the code.  I can't reproduce
the infinite loop myself, but Leon says he can reproduce the problem, and if
it's so then it's a problem (Murphy's Law), and I definitely see that it is
possible to add an attribute then later while a write is occuring to ... for
instance ... be logged in to some application which is relying on session
variables and the system think you are not then get kicked out because of
concurrency issues in with the HashMap not being synchronized because the system
thinks a session attribute/variable isn't set when it is.  The original set
could have occurred hours before then just when the read is occuring a write
takes place which resizes the HashMap, and then an issue arises which makes web
apps unpredictable in Tomcat....you can predict it by knowing the default size
of the Map and not using more session variables than the Map threshold to size I
suppose, but give me a break.  I can't say for certain, myself, whether the
infinite loop will occur just syncing the writes or not, but the way the get
method works with the index being calculated for the hash bucket (array index)
you can certainly say it's unpredictable and it can definitely cause goofy
errors.  So an INVALID resolution seems irresponsible for this issue.

-- 
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