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 15:03:08 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-08 17:03 -------
(In reply to comment #44)
> I guess I should add that it seems logical if one web page calls
> Session.setAttribute then it shouldn't be possible later to make a call to
> getAttribute and it not be available.  i.e. a minute earlier I made a call to
> set then a minute later during my get a resize occurs and I get a null even
> though I should not get a null.  This could occur because of the bucket
> distribution on certain hash and table size combinations vary.  I had one hash
> and table combination yield a 9 index.  Later when the resize occured this index
> was moved to 3, and the resize before that it was moved to 11.  So, start at 9,
> resize, then to 11, resize, then to 3.  So you can imagine what would happen if
> during the time I get the hash from indexFor and then access the array what I
> might get....null.  This all in HashMap.get

This even without speaking of the infinite loop 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