[jboss-jira] [JBoss JIRA] Closed: (JBCACHE-1326) TxInterceptor leaks MethodCall to thread

Tue Apr 8 22:47:54 EDT 2008

     [ http://jira.jboss.com/jira/browse/JBCACHE-1326?page=all ]

Brian Stansberry closed JBCACHE-1326.
-------------------------------------

    Fix Version/s:     (was: 2.2.0.GA)
       Resolution: Done

> TxInterceptor leaks MethodCall to thread
> ----------------------------------------
>
>                 Key: JBCACHE-1326
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1326
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transactions
>    Affects Versions: 2.1.0.GA
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: 2.1.1.GA
>
>
> The various Synchronization callbacks in TxInterceptor end up calling the equivalent of cache.getInvocationContext().setMethodCall(xxx) but then don't restore the InvocationContext to its previous state when done.  All other calls to InvocationContext.setMethodCall() do reverse themselves after the call is executed, so the effect is whatever MethodCall a TxInterceptor synchronization last associated to a thread ends up staying with that thread until some random other synchronization changes it to something different.
> This is showing up in the AS as a classloader leak, since the leaked MethodCall has a ref to undeployed classes. If a server had a large thread pool, the leak could be long lasting.
> I've added an assertion to org.jboss.cache.invocationcontext.TransactionTest.doScrubbingTest that shows the problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira