[jbossts-issues] [JBoss JIRA] (JBTM-3325) Create a way to close XAResource at the end of the recovery cycle processing

Luis Barreiro (Jira) issues at jboss.org
Tue Jun 23 11:30:55 EDT 2020


    [ https://issues.redhat.com/browse/JBTM-3325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14172931#comment-14172931 ] 

Luis Barreiro commented on JBTM-3325:
-------------------------------------

Thanks [~ochaloup] for bringing up this topic.

Agroal takes a different approach than IronJacamar on recovery. It was debated internally, and the conclusion was that it's better to open a new connection every time than to have to manage the connection. To prevent leaks in this scenario, there must be a way to notify that recovery scan has ended. Ideally, this would be done in either 1) the {{XAResource}} itself, or 2) {{XAResourceRecovery}} as a counterpart of {{getXAResources()}}. The former is impossible to change, for obvious reasons, and I don't see any will to make changes to the latter.

I asked for feedback on how to manage the connection liyfecycle and [~mmusgrov] suggested to close the connection on {{TMENDRSCAN}}. Agroal now checks for it and it fixed the connection leaks that were being reported. I then suggest to go beyond that and have the {{XAResource}} implementation to express it's intention to be notified that it's no longer needed by implementing a marker interface, in this case I suggested {{AutoClosable}}. I believe this would be the cleanest way to deal with this problem, given the circumstances. This would be an alternative to 1) above.

If [~jhalliday] it's right then it's really concerning, because not only it means that the current implementation is wrong and there is no reliable way to get notified of the end of the recovery, but it also implies that Narayana does not have control on the recovery procedure which baffles me. 
 
Go back to keep a connection open for recovery is always an option, but it comes with it's own drawbacks and implementation challenges. I much rather see the effort put into having a reliable way to notify the end of recovery.

> Create a way to close XAResource at the end of the recovery cycle processing
> ----------------------------------------------------------------------------
>
>                 Key: JBTM-3325
>                 URL: https://issues.redhat.com/browse/JBTM-3325
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: JTA
>    Affects Versions: 5.10.5.Final
>            Reporter: Ondrej Chaloupka
>            Assignee: Ondrej Chaloupka
>            Priority: Major
>
> From discussions about Narayana integration to Agroal (https://agroal.github.io/) there came an idea how to make easier for Agroal to integrate with Narayana recovery processing.
> Usually (or at least Agroal does so) the brand new {{XAResource}} is provided from the call of the {{XAResourceRecovery}} (https://github.com/jbosstm/jboss-transaction-spi/blob/7.6.0.Final/src/main/java/org/jboss/tm/XAResourceRecovery.java#L51).
> aka. Agroal implements the {{XAResourceRecovery}} and register it with the Narayana with adding it to with https://github.com/jbosstm/jboss-transaction-spi/blob/7.6.0.Final/src/main/java/org/jboss/tm/XAResourceRecoveryRegistry.java to be used in {{XARecoveryModule}}.
> When the periodic recovery cycle ends the {{XAResource}} is not used (next time the recovery processing calls the {{XAResourceRecovery#getXAResources()}} to get the resource for scanning again). The transaction manager announces that the scan ended with call {{XAResource.recover(XAResource.TMENDRSCAN)}} (this is an internal to how Narayana works).
> It would be beneficial provide an option that Narayana closes {{XAResource}}s at the end of the recovery cycle when Narayana does not plan to use it again.
> The idea is to check if the {{XAResource}} is {{AutoCloseable}} and if so then the {{XAResource}} is closed at the end of the recovery cycle processing.



--
This message was sent by Atlassian Jira
(v7.13.8#713008)


More information about the jbossts-issues mailing list