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-08 16:58 ------- (In reply to comment #38) > I think the trouble without any sync could only occur if there was more than > one > concurrent unsynced write, and in particular, two "remove"), the pointer value > will be corrected and the loop should exit. That's my interpretation looking > at If I understand this statement correctly - You are saying that syncing the put and remove should be enough to stop the infinite loop, and that this is why it was "FIXED" in 5.5. If an example could be provided that an unsynced get can lead to an infinite loop, would this change anything concerning the status of this problem? A second question following on from this: When would anyone want to use a "threadUnsafe" session set/getAttribute? As we have seen, NOT syncing this causes hangs - so therefore developer needs to do this (if he uses these methods). Wouldn't it make more sense to just sync it further down in tomcat, as suggested here, rather than needing to sync the whole method every single time you use this in your code? -- 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]
