Jesper Pedersen [
http://community.jboss.org/people/jesper.pedersen] replied to the
discussion
"JcaXAResourceRecovery"
To view the discussion, visit:
http://community.jboss.org/message/541069#541069
--------------------------------------------------------------
I may be misunderstandin ghte model, but it seems that
ManagedConnectionFactoryDeployment.getXAResources() creates a new connection on each call,
which is good in that if the db crashes and recovers whilst the app servers stays up, the
system will effectively reconnect rather than continuing to use a stale connection.
However, as far as I can tell, it's never disposing those connections. Since the
recovery system will make one pass every two minutes by default, it's going to leak
pretty badly. The integration SPI does not allow for explicit disposal, so the best bet
is probably to keep a handle on the last connection used and on each call to
getXAResources either validate it (i.e. ping the db to make sure it's still there) and
reuse it, or explicitly release it and get a new one.
Fixed. Thanks.
As to the explicit close case - I need to know when recovery have been done in order to
cleanup and destroy the managed connection, and the JCA API doesn't have an SPI for
that (yet). Maybe we could add recoveryBegin() and recoveryEnded() to our interface ?
As to the validate case - I'll think about what we can do to best handle this case and
commit something, if we aren't going with the idea above.
The XAResourceWrapperImpl usage appears to be applied only to
XAResources used for recovery, not he ones used during normal transaction usage. It would
be helpful to have the same wrapping applied to the XAResource handed out to the
transaction manager during normal operation, as that would allow correlation in the logs
between the tx run and the recovery. I'm guessing that's a fairly minor cutnpaste
type fix - any chance of squeezing it in?
Normal transaction usage is handled in the TxConnectionManager class, where the interface
is used (if enabled). So we should be good in that case :)
There is room for a lot of improvements both in the JCA spec and the JCA container to make
life easier for our users - I'll keep this in mind for the new implementation.
--------------------------------------------------------------
Reply to this message by going to Community
[
http://community.jboss.org/message/541069#541069]
Start a new discussion in JCA Development at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=1&...]