[ https://issues.redhat.com/browse/JBTM-3325?page=com.atlassian.jira.plugin... ] Michael Musgrove commented on JBTM-3325: ---------------------------------------- A few of points: 1. It is normally the application servers job to close connections. This method can potentially break assumptions made by the app server. 2. The resource adaptor can be shared by multiple threads so all other threads that are potentially using the adaptor need to be notified. Agroal probably knows how to handle that but can we be sure that other adaptors do too. You may argue that you have made it configurable, but the accompanying PR sets this behaviour globally so all resource types will be expected to handle the close correctly (and be expected to work with the application servers' connection management policies). Again, basically it is the app servers job to close connections. 3. A TM can have a connection to an RM via more than one resource adaptor and the 'XAResource#isSameRM' method is provided to tell the TM when that is the case. What effect will your closing of one of them have on the other resource adaptors that connect to the same RM? 4. Finally TMENDRSCAN is not to tell the resource adaptor that the scan has ended. It is the resource adaptors job to tell the TM when the scan has finished and it does that in 'int xa_recover(..)' by returning an int that the caller uses to determine whether the passed in array is full or not. If the caller did not supply a big enough array then the caller can keep calling the recover method until the cursor has reached the end of the list of prepared branches. The caller tells the resource to reset its cursor using the TMENDRSCAN flag. Remark: JTA is a layer over XA and is somewhat vague on the usage of this flag, in fact the spec does not even discuss it. I would expect it is never used since in a Java environment the resource returns a Java array from the recover call whereas in the XA API the caller supplies the array. I think this issue should be discussed within the community before making the change. -- This message was sent by Atlassian Jira (v7.13.8#713008)