You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Antranig Basman (JIRA)" <ji...@apache.org> on 2007/05/30 17:07:15 UTC
[jira] Created: (TRANSACTION-15) Lightweight transaction leaks on
exception from FileResourceManager.getResource
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
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/%3c44723466.32EF7DE@caret.cam.ac.uk%3e
(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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Updated: (TRANSACTION-15) Lightweight transaction leaks on
exception from FileResourceManager.getResource
Posted by "Antranig Basman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TRANSACTION-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Antranig Basman updated TRANSACTION-15:
---------------------------------------
Attachment: transaction-lightweight-fix.txt
Fix and testcase for issue
> 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: 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/%3c44723466.32EF7DE@caret.cam.ac.uk%3e
> (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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Resolved: (TRANSACTION-15) Lightweight transaction leaks on
exception from FileResourceManager.getResource
Posted by "Oliver Zeigermann (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TRANSACTION-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oliver Zeigermann resolved TRANSACTION-15.
------------------------------------------
Resolution: Won't Fix
Lighweight transactions were a really bad idea. Please avoid them. There will be no equivalent for them in 2.0.
> 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
> Assignee: Oliver Zeigermann
> 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/%3c44723466.32EF7DE@caret.cam.ac.uk%3e
> (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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Updated: (TRANSACTION-15) Lightweight transaction leaks on
exception from FileResourceManager.getResource
Posted by "Oliver Zeigermann (JIRA)" <ji...@apache.org>.
[ 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/%3c44723466.32EF7DE@caret.cam.ac.uk%3e
> (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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Commented: (TRANSACTION-15) Lightweight transaction leaks on
exception from FileResourceManager.getResource
Posted by "Oliver Zeigermann (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TRANSACTION-15?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502945 ]
Oliver Zeigermann commented on TRANSACTION-15:
----------------------------------------------
Concerning your observations with light weight transactions I can only agree. They really are not very robust and have to be used with extreme care.
I would like to see them fixed as well, but it is as easy as this: No patch, no fix ;)
As a workaround use full transactions.
> 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
> Assignee: Oliver Zeigermann
> 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/%3c44723466.32EF7DE@caret.cam.ac.uk%3e
> (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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Commented: (TRANSACTION-15) Lightweight transaction leaks on
exception from FileResourceManager.getResource
Posted by "Antranig Basman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TRANSACTION-15?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511915 ]
Antranig Basman commented on TRANSACTION-15:
--------------------------------------------
Thanks for your patch, which looks good for the earlier reported issue (in the May 2006 thread). However the supplied patch here and report are for a different issue, an exception safety issue in FileResourceManager - please could you review the patch - cheers :)
> 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
> Assignee: Oliver Zeigermann
> 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/%3c44723466.32EF7DE@caret.cam.ac.uk%3e
> (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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org