Bug JBTM-532 and JBoss Transactions 4.11

[mauromol]

Hello, I recently upgraded JBossTS from 4.6.1 GA to 4.11 Final. I see that bug JBTM-532 that I opened against 4.5 and 4.6 should have been fixed in 4.8.0. However, I have a doubt on the current implementation of com.arjuna.ats.internal.jdbc.ConnectionImple.close().

I mean, if _theModifier is null, a comment says: "no indication about connections, so assume close immediately". However in this case only _theConnection is closed and set to null, while _recoveryConnection.closeCloseCurrentConnection() is not called. I think this may lead to connection leaks.

What I would expect is that if _theModifier is null, a log entry were added but nothing else were done; in particular I would expect not to return and let the following "if (!delayClose)" (towards the end of the method) close the connections immediately (both _theConnection and _recoveryConnection).

Before diving in debugging our application while monitoring the DBMS, I would like to know what JBossTS developers think about this and if I should open a JIRA.

Thanks in advance,

Mauro.

[marklittle]

Open a JIRA. It can always be rejected later.

[mauromol]

Hi Mark, I opened JBTM-789 at https://jira.jboss.org/browse/JBTM-789 I would appreciate some feedback. Thank you!

[jhalliday]

The jdbc module is in limbo pending our evaluation of the new standalone JCA. With this week's beta release it gained the ability to do -ds.xml deployments, so we can hopefully now make progress on that eval. If we decide to keep the jdbc module rather than junking it in favor of a TS+JCA bundle then we'll handle this issue as part of the jdbc renovation work that will be needed. Don't expect any changes until 4.14 at the earliest. Meanwhile you could try out the new JCA instead if you like.

[mauromol]

Hi Jonathan, thanks for your reply.

What is JCA? Is it about JEE Connector Architecture? Can be TS+JCA used outside a JEE application server (in Tomcat, for instance)? Is there any documentation available on how to use TS+JCA instead of the JDBC module? How does JCA match with JDBC?

As of now we are using JBossTS JTA embedded into our web application, using Spring to manage the transactions (which span multiple databases, one controlled with Hibernate and others with a proprietary ORM) and JBossTS JTA as our JTA-XA implementation. We're using the JBossTS TransactionalDriver and the DynamicClass mechanism (instead of JNDI) to get the XADataSources from which to pull the XAConnections. Is this reproducible with JBossTS+JCA?

Anyway, the problem I'm describing here is very circumscribed and I have also proposed a very simple solution (if my assupmtions are right)... so maybe you could help even if the future of the JDBC module is uncertain right now?

Thanks in advance,

Mauro.

[marklittle]

Have you tried your suggested change? If not, give it a go and respond back here. I may get a chance to try it out too, but at the moment it's not a priority for us, as Jonathan has outlined.

[mauromol]

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.

[marklittle]

Hi Mauro. I'll take a look as soon as I have a chance.