Hi Fred
On Tuesday 15 January 2013 06:50 PM, frowe_at_us.ibm.com wrote:
> When performing recovery and processing inbound messages, we get an
> XAResource from the resource adapter by invoking the method
> getXAResources(ActivationSpec[] specs). For those returned XAResource
> objects, what is the expected means to destroy them since there is no
> API method to do so?
I assume the point here being that there is an implicit
Connection leak (a Connection to the EIS that was backed by the
XAResource and was used for recovery) as there is no indication
to the RA to close the XA resource (and the underlying connection).
This issue was discussed a lot in the JSR 322 EG. Here was the
conclusion the EG reached.
--- edited notes ---
Description/Analysis:
Any approach to address this assumes in some form or
other that the container is aware of when a tx
recovery is complete. This was deemed to be complex in
certain peer-to-peer transaction recovery
mechanisms that may not be aware of such a completion
and hence may be unable to provide the notification to
the RA to indicate the completion of use of the XAResource.
A XAResource may also be reused by the AS even after
tx-recovery. It might be complex for TM to track which
recovered transaction is gotten from which XAResource
instance originally. A TM is free to use any isSameRM()
instance, and is not limited to the original one.
It was suggested that even with the above constraints,
the RA does not need to know the recovery is complete
and when it can release XAResources and underlying connections,
and a proposal to add a new BootstrapContext method
release(XAResource xar) which may be called by the AS whenever it decides
it doesn't need the XAResource instance was made.
This method could be called after recovery completes or even before.
This was proposed as an optional notification from AS, and
AS may not call it depending on AS's implementation.
Even with this approach it was pointed out that
there may not be much use if it is made optional for the
AS and if made mandatory, an AS using a peer-recovery
mechanism, described above, may not be able to implement
it.
Conclusion:
Since there was no alternative, we abandoned
resolving this issue, as it was not very critical
in JSR-322 and workarounds existed (see below).
Workaround:
There were workarounds suggested to get around this issue:
- An AS may stop() the RA post tx-recovery, and start() again
to get around the connection leak (as the RA can stop all connections
in the stop() method).
- The RA also may wrap all XAResources it provides to the AS,
and determine tx recovery completion and close the
underlying connection.
--- edited notes ---
Thanks
--Siva.