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 Fri, 09 Sep 2005 00:10:33 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 02:10 -------
(In reply to comment #58)
> 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
> 
> 
> 

Again though, when you look at all of the places accessing Session.getAttribute
you can't synchronize all of them, so the last question that I see is what is
going to be fixed?  Either all of these other places in TC need to be fixed or
this one does.  But, I think a real world study should take place before all the
 other places are fixed and this one isn't.  I mean, if all other containers are
behaving like TC4.x and synchronizing these calls then it just makes sense for
TC to follow suit.

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