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=31105>. 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=31105 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |critical ------- Additional Comments From [EMAIL PROTECTED] 2005-04-04 09:56 ------- This bug is also a memory leak, that's why I changed the severity to critical. To prevent the memory leak from occuring I changed ExtendedStore in almost the same way as Steve did. The difference is that I don't release the transient locks in end(...), but only do this in forget(...), rollback(...) and commit(... ). Looking at the logs I saw that after a suspend one of forget(...), rollback(. ..) and commit(...) will be called. I don't know if this happens when an end or a fail is passed to end(...). If it does the releasing of the locks in end(...) is not necessary. I am interested to know what the answer to the question in Steve's patch, 'Do we want to throw away the locks when joining?', is. -- 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]
