Unfortunately I discovered this thread just now, although I talked about this topic with Mark Little last October in: http://community.jboss.org/message/565137.

Is there any documentation that explains what is going on this subject? Will JBossTS be still usable for JDBC connections? In what would consist the migration?

We're using JBossTS in a JTA infrastructure where database queries are done through JDBC. The client code just uses JDBC connections (obtained through the transactional driver), while the global JTA transaction is controlled using Spring JTA transaction manager. The JBossTS backend, through the transactional driver and some of our glue code, is obtaining JTA connections through XA data sources created using the DynamicClass mechanism. We're working outside JEE, just plain Tomcat + JBossTS + Spring.

How will the scenario change with JCA?

Mauro.

Hi Tom,

first of all thank you for this first answer.

I had a very quick look at the IronJacamar documentation. Although I see a chapter called "embedded use", I find it quite synthetic, so my first concern is how easy would be to use the JCA connector in an embedded way, I mean outside a JEE container, without needing JNDI or such.

We spent a lot of effort to make JBossTS work embedded in our application, submitted bugs and helped to fix them (or, at least, to understand them). Right now, our infrastructure is like this:

• the client code requests a plain JDBC connection to a proprietary ConnectionManager; it uses the connection to do SQL statements; after that, the global JTA transaction is committed or rolled back through the use of Spring JtaTransactionManager
• our ConnectionManager simply has a reference to a DataSource implementation which pulls connections from a JDBC driver (without pooling); in our case, the JDBC driver is the JBossTS transactional driver; on the other hand our Spring JtaTransactionManager is configured in order to use the JBossTS JTA transaction manager as the JTA-XA implementation
• the transactional driver is configured through the use of the dynamic class mechanism; our dynamic class implementation is able to pull XA DataSources based on a proprietary XML-based configuration which tells the dynamic class which JDBC XA implementation driver to use to create XA Data Sources and how to wrap those XA Data Sources in order to provide pooling functionality to XA connections and other adjustments needed to make the whole thing work correctly (things like specific exception handling, "is-same-RM" overriding behaviour and other things alike)

I don't know anything about JCA connectors, apart from the definition, but quickly reading some documentation, this is the idea of what our system would become. I hope in this way to help you to understand my gaps. Please, correct me if I say something wrong.

• our client code would not be touched; it would still use plain JDBC connections pulled out from out ConnectionManager in order to make SQL statements; the global JTA transaction will always be controlled through the Spring JtaTransactionManager
• our ConnectionManager would pull connections from a DataSource provided in some way by the IronJacamar JCA connector embedded in our application; on the other hand, our Spring JtaTransactionManager configuration would not be affected, it would still use the JBossTS JTA transaction manager to orchestrate the global JTA transaction
• the IronJacamar JCA connector embedded in our application will take care of all the hassle of creating and managing XA Data Sources from the JDBC implementation driver, of doing the connection pooling and of applying implementation-specific hacks and tricks (like the "is-same-RM" overriding thing); to be able to do this, I think it would need some adapter (a resource adapter?) for JDBC-XA; from what I've understand, JCA is also JTA-ready, so I can imagine that this JDBC JCA adapter is also responsible of mapping the JTA transaction orchestration to the JDBC XA connection level... so I may expect that this resource adapter is provided by JBossTS JTA

Am I right? Am I totally wrong? Are there other things that must be considered in this scenario?

Thank you very much in advance!

Mauro.