You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While most vendors (MQSeries, Tibco, etc.) do not have this requirement, it appears that some (such as HornetQ) require that end be called eagerly as a result of delistResource being called. Whlle section 4.2 of the JTA spec sites this as an example case/implementation it also explains that “This session provides a brief walkthrough of how an application server may handle a connection request from the application. The figure that follows illustrates the usage of JTA. The steps shown are for illustrative purposes, they are not prescriptive:”
Further the JCA 1.7 section 7.6.5 states “
4. The application server dissociates the XAResource instance, corresponding to the ManagedConnection instance, from the transaction manager using the method Transaction.delistResource.
5. The transaction manager calls XAResource.end(Xid,flag) to inform the resource manager that any further operations on the ManagedConnection instance are no longer associated with the transaction, represented by the Xid passed in XAResource.end call. This method invocation dissociates the transaction from the resource manager instance.
6. After the JTA transaction completes, the application server initiates a cleanup of the physical connection instance by calling ManagedConnection.cleanup method. After calling the method cleanup on the ManagedConnection instance, the application server returns the ManagedConnection instance to the connection pool.
"
and/but the JTA spec states only that “A container only needs to call delistResource to explicitly disassociate a resource from a transaction and it is not a mandatory container requirement to do so as a precondition to transaction completion. A transaction manager is, however, required to implicitly ensure the association of any associated XAResource is ended, via the appropriate XAResource.end call, immediately prior to completion; that is before prepare (or commit/rollback in the onephase-optimized case). “
Therefore, it would be good to specification/clarify this in the JTA (and perhaps JCA as well) specification(s) on way or another. We could additionally perhaps come up with some option for the call to delistResource to eagerly result in the XAResource.end call by the TM for the TMSUCCESS and TMFAIL flag cases.
The text was updated successfully, but these errors were encountered:
While most vendors (MQSeries, Tibco, etc.) do not have this requirement, it appears that some (such as HornetQ) require that end be called eagerly as a result of delistResource being called. Whlle section 4.2 of the JTA spec sites this as an example case/implementation it also explains that “This session provides a brief walkthrough of how an application server may handle a connection request from the application. The figure that follows illustrates the usage of JTA. The steps shown are for illustrative purposes, they are not prescriptive:”
Further the JCA 1.7 section 7.6.5 states “
4. The application server dissociates the XAResource instance, corresponding to the ManagedConnection instance, from the transaction manager using the method Transaction.delistResource.
5. The transaction manager calls XAResource.end(Xid,flag) to inform the resource manager that any further operations on the ManagedConnection instance are no longer associated with the transaction, represented by the Xid passed in XAResource.end call. This method invocation dissociates the transaction from the resource manager instance.
6. After the JTA transaction completes, the application server initiates a cleanup of the physical connection instance by calling ManagedConnection.cleanup method. After calling the method cleanup on the ManagedConnection instance, the application server returns the ManagedConnection instance to the connection pool.
"
and/but the JTA spec states only that “A container only needs to call delistResource to explicitly disassociate a resource from a transaction and it is not a mandatory container requirement to do so as a precondition to transaction completion. A transaction manager is, however, required to implicitly ensure the association of any associated XAResource is ended, via the appropriate XAResource.end call, immediately prior to completion; that is before prepare (or commit/rollback in the onephase-optimized case). “
Therefore, it would be good to specification/clarify this in the JTA (and perhaps JCA as well) specification(s) on way or another. We could additionally perhaps come up with some option for the call to delistResource to eagerly result in the XAResource.end call by the TM for the TMSUCCESS and TMFAIL flag cases.
The text was updated successfully, but these errors were encountered: