[ https://issues.apache.org/jira/browse/TRANSACTION-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oliver Zeigermann updated TRANSACTION-15: ----------------------------------------- Attachment: patch.txt As far as I can see your patch only has a suggestion for the removal of unused owners. As discussed in the thread you state this may fail in certain scenarios where another thread adds a new log for that specific owner. That is possible as in common tx you can have more than one thread per owner (not really a good idea, though). My recent commit, shown in the patch, takes over your idea and tries to take the above argument into account. Please check if that fixes the bug. > Lightweight transaction leaks on exception from > FileResourceManager.getResource > ------------------------------------------------------------------------------- > > Key: TRANSACTION-15 > URL: https://issues.apache.org/jira/browse/TRANSACTION-15 > Project: Commons Transaction > Issue Type: Bug > Affects Versions: 1.1, 1.2 > Environment: Current trunk of rev 542554 > Reporter: Antranig Basman > Attachments: patch.txt, transaction-lightweight-fix.txt > > > FileResourceManager getResource(String) method will leak in the case an > exception occurs during execution, in the most obvious case where the > resource does not exist. This is because the method does not do proper > cleanup of the lightweight transaction (which it allocated itself). > Lightweight transactions in general are pretty sketchy in commons-transaction > which I think is a fact that should be advertised a bit more widely - I was a > little disappointed to see that the 1.2 release went ahead last month without > any more attention to the issues that I raised last May - the thread begins > 22nd May 2006 at > http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200605.mbox/[EMAIL > PROTECTED] > (title: Memory leaks in GenericLockManager, FileResourceManager) > The resolution to the leak I posted there was demonstrated not completely > sound, but I think in the absence of any other approach it would be better > than nothing - better that a heavyweight transaction immediately retried with > the same ID will very rarely fail than that every lightweight transaction > will leak :P > In any case, this issue is more serious in that it is not just a leak, but > will permanently lock a part of the resource tree for the lifetime of the > ResourceManager. I have attached diffs for a patch and a test case for this > issue below. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]