[jbossts-issues] [JBoss JIRA] Created: (JBTM-464) Provide a way to dispose the TxControl

Mauro Molinari (JIRA) jira-events at lists.jboss.org
Thu Jan 15 04:45:05 EST 2009

Provide a way to dispose the TxControl

                 Key: JBTM-464
                 URL: https://jira.jboss.org/jira/browse/JBTM-464
             Project: JBoss Transaction Manager
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Transaction Core
    Affects Versions: 4.4.0.GA
            Reporter: Mauro Molinari

We're using JBossJTA embedded in our webapp, so it is deployed with our webapp.
In this context when the webapp is stopped we need to shutdown JBossJTA completely.
However, there are some leaks that are causing the webapp classloader not to be garbage collectable.
One is addressed by JBTM-462.

Another is caused by com.arjuna.ats.arjuna.coordinator.TxControl. In fact:
- a shutdown hook is registered by TxControl and can't be unregistered
- that shutdown hook calls finalize() on the TransactionStatusManager which is responsible of stopping the recovery listener

Apart from the fact that it sounds quite strange that a finalize method is used to shutdown something, the problem is that:

- the TransactionStatusManager is a field of TxControl with package visibility, so there's no way to access it from outside the TxControl and/or another class of the same package
- TxControl does not have any public shutdown/dispose static method: this method shut unregister the shutdown hook and call TransactionStatusManager.finalize()
- even if com.arjuna.ats.internal.arjuna.recovery.Listener.stopListener() calls interrupt() to stop the recovery listener thread, in my tests I observed that the thread is not actually interrupted (it seems that java.net.ServerSocket.accept() doesn't honour the interrupt method by interrupting itself...), so if the property com.arjuna.ats.internal.arjuna.recovery.listener.timeoutsocket in jbossjta-properties.xml is set to NO or is not set (which seemed to be the default in my configuration...), the recovery listener thread waits undefinitely and never stops, even if Listener.stopListener() is called

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


More information about the jbossts-issues mailing list