Hi Mark,
sorry for the delay, I was busy on other fronts.
Yes, I tested my suggested change: the _recoveryConnection must always be closed together with _theConnection. However, as I said before, this is just part of the problem. The real issue is that it's not correct to close connections immediately, even if _theModifier is null (it's actually always null in our configuration). Our product currently supports the following DBMSes: PostgreSQL, SQL Server, Oracle and H2. With all of them, the correct approach to follow is to register a transaction synchronization so that _recoveryConnection and _theConnection are ALWAYS closed AFTER transaction termination.
This sentence is confirmed by some unit tests I'm running on H2. If I leave the "close immediately" default behaviour, strange things happen, like:
1) you commit a one-phase transaction and changes are not persisted
2) TRANSACTION_NOT_FOUND errors coming from the JDBC driver when trying to commit
My suspect is that closing a connection before transaction termination causes the DBMS to release the transaction resources associated with that connection, actually destroying (by rolling back) the transaction. This would explain both of the strange behaviours I observed.
I don't know if the same problems might occur on PostgreSQL, SQL Server or Oracle, but what I can say for sure is that always closing connections after transaction termination does not harm and makes the whole picture work like a charm.
I hope this is of help for you to revisit that part of the code. If you need more details on my configuration please let me know.
Please, do not abandon the JDBC component!!! It's essential to use JBossTS JTA embedded (as we do), without the need for a JEE/JCA/etc. infrastructure. I've always helped in this area by submitting bug reports and suggested fixes in JIRA, so if you need some help to maintain it (at least with current functionalities) I may try to do my best to help you.
Thanks in advance,
Mauro.