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:45:29 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 andrewm@2sheds.de  2005-09-09 01:45 -------
I assume that everyone has read the tomcat mailing list regarding this issue
and seen and read the link pointing to

http://blogs.opensymphony.com/plightbo/archives/000175.html

So are we still arguing whether or not getAttribute can cause an infinite loop?
or not?

If we all agree that getAttribute can cause an infinite loop IF called in a 
multithreaded environment, we (I assume) all agree that the call to it MUST be
synced SOMEWHERE. This also includes the example in comment 46, as it can not
be gaurenteed that getAttribute (inside the session.get) in the first line 
does not happen in the middle of putAttribute in the middle of session.put.

Now the last question is remaining is who's responsibility is it to sync it?

If the end developers need to sync it - they will need to sync much more than 
just the 'hashmap' itself




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