Announcement Announcement Module
No announcement yet.
JTA - XA Datasources Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • JTA - XA Datasources

    Should we use XA-Datasources in datasource bean definitions when using JtaTransactionManager as the transaction management strategy.

    What will we gain when using oracle.jdbc.xa.client.OracleXADataSource
    instead of oracle.jdbc.pool.OracleConnectionPoolDataSource

  • #2
    There's not much of a reason to use an XA datsource if you don't actually need XA (two phase commit, basically) capabilities, and/or your environment (like the DB) doesn't support XA. So if you only point to one datasource, then you're not going to get anything extra. On the driver side, for example, PostgreSQL JDBC drivers don't currently support XA. So trying to use them in an XA setup would not give you proper two phase commit. On the other hand, if you do have two different datasources (or more), and the drivers and the datasources do support XA, then you will get proper @PC sematics, with proper handling of comit and rollback among the different enlisted datasources.


    • #3
      Thanks for the reply Colin. I will tell you the exact scenario:
      - I have multiple datasources.(Oracle,DB2,AS400)
      - using Spring+Hibernate
      - using JtaTransactionManager as transaction mgm.

      I will define all of 3 datasources in applicationConfig.xml and will define 3 hibernateSessionFactories for them. What I wonder is ,if I use regular DataSources(i.e. oracle.jdbc.pool.OracleConnectionPoolDataSource) for datasource definitions instead of XA DataSources, will Spring be comfortable with this configuration and guarantee the commit,rollback operations when these 3 datasources involved in a distributed transaction.

      Thanks in advance.


      • #4
        Well, Spring can't perform magic :-) If you need 2 phase commit, then you need to be using real 2PC capable datasources, and an environment that supports them. So this means JTA + XA capable jdbc drivers plus XA capable databases. It's JTA that's going to coordinate the commits or rollbacks, and it needs the support from the drivers and the dbs. Even if for example you took JTA out of the picture and there was an equivalent 2PC capable TM in spring, it still couldn't do it's work without the capability in the drivers and dbs.