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=34227>. 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=34227 ------- Additional Comments From [EMAIL PROTECTED] 2005-03-31 03:19 ------- (In reply to comment #6) > On thing is for sure, we're not going to add any synchronization for this. If > something goes away, it will be the call to endAccess (which was added due to > *one* user whining about a stupid use case). I think a hack should be added > instead (if the inactivity period gets too long or something). > > I do not understand the problem still: is it actually the accessCount int which > ends up having the wrong value due to concurrent access ? That's actually almost > impossible. Yes the accessCount within StandardSession is bumped up to 2 during concurrent request (StandardSession.access() increment call) and after both requests are completed it remains with value 1. The recycle on the CoyoteRequest is where endAccess is called that decrements. Somehow the second request no longer has the session object to call the endAccess the second time. Note: this does not always happen - hence race condition. I agree its difficult to time but a machine can do it easily via browser multiple background download calling servlets that execute in nearly equal time. I also agree that synchronizing is not a desired solution to this. -- 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]
