[jboss-jira] [JBoss JIRA] Commented: (JBCACHE-1007) Synchronization impls should scrub state in afterCompletion

Thu Mar 15 09:33:32 EDT 2007

    [ http://jira.jboss.com/jira/browse/JBCACHE-1007?page=comments#action_12356195 ] 

Manik Surtani commented on JBCACHE-1007:
----------------------------------------

Also see 

http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028359#4028359

which may be related.

> Synchronization impls should scrub state in afterCompletion
> -----------------------------------------------------------
>
>                 Key: JBCACHE-1007
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1007
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>         Assigned To: Manik Surtani
>            Priority: Minor
>             Fix For: 2.0.0.CR1
>
>
> I've seen cases where transaction manager's hold refs to Synchronization objects for a while after the tx commits.  This can give the appearance of memory leaks if the Synchronization holds state and someone is testing for leaks of objects linked to that state. Also, a user reports that JOTM is not releasing refs to Synchronizations, thus leaking anything referred to from the Synchronization (see forum thread.)
> Solution to this is to have the Synchronization clear its internal state in a finally block in afterCompletion().  Once that method executes, the state is no longer needed. See http://www.jboss.com/index.html?module=bb&op=viewtopic&t=104067 for more on this. 
> If possible, it's also good to have the Synchronization impl be a static class, so there is no, for example, TxInterceptor.this ref leading back to the interceptor from TxInterceptor$RemoteSynchronizationHandler.
> This is a minor issue, since if the TM does what it should and eventually drops the ref to the Synchronization, the issue cleans itself up.  But clearing the Synchronization state aggressively helps avoid the appearance of leaks, and also helps unit tests that check for classloader leaks to ignore spurious stuff.

-- 
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