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=40380>. 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=40380 ------- Additional Comments From [EMAIL PROTECTED] 2006-12-27 01:42 ------- Just to butt in here. The easiest fix is to move or copy the if(expiring) inside the synchronized() section. Does such a large block have to be synchronized(this) {} ? I can't see any other code using synchronized(this) in the class (or synchronized(session) in the package), so I guess the only thing being protected is the if(expiring==false) { expiring=true; } test and set. As things stand now is the StandardSession author sure there is no issue of needing to make the JVM perform a memory write barrier ? To ensure that expiring=true is flushed for other threads see it immediately. Otherwise the JVM maybe free to optimize (and defer) this write to memory (unless you start getting into declaring 'expiring' volatile). Suggestion: if (expiring) return; synchronized (this) { if (expiring) return; if (manager == null) return; expiring = true; } // From here is no need to keep the lock AFAIKS and by closing the synchronized() we will ensure memory write barrier. // Towards the end of the function it sets expiring=false; I dont think the any code in critical to seeing the expiring==false again, not once isValid==false in anycase. -- 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]
