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