commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Zeigermann (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (TRANSACTION-15) Lightweight transaction leaks on exception from FileResourceManager.getResource
Date Fri, 13 Jul 2007 18:08:05 GMT

     [ 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


Mime
View raw message