[ 
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/[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]

Reply via email to