how to get XADatasource using JNDI look up for Atomikos Transaction Management

Question

I am configuring Atomikios TM API with my Spring Application to achieve global transaction. As Atomikios require XADatasource to work, so I have done JNDI look up to get the same. But, unfortunately I am getting following errors while doing the look up.

Object of type [class com.ibm.ws.rsadapter.jdbc.WSJdbcDataSource] available at JNDI location [jdbc/cuds] is not assignable to [javax.sql.XADataSource]

<jee:jndi-lookup id="dataSourceCu" jndi-name="jdbc/cuds" cache="true" resource-ref="true" lookup-on-startup="true" expected-type="javax.sql.XADataSource" />
<jee:jndi-lookup id="dataSourceGodb" jndi-name="jdbc/pushpullds" cache="true" resource-ref="true" lookup-on-startup="true" expected-type="javax.sql.XADataSource" />

I am using Spring 3.0/ hibernate with WebSphere 7.0.Where I am doing wrong. Please help me. Thanks.

Answer 1

The data source configured under jdbc/cuds is not an XADataSource but a normal one. You need to change the data source configuration in WebSphere (I have no idea how to do this).

However since you're on WebSphere which has it's own transaction manager there really is no need for configuring Atomikios. You can either use

<tx:jta-transaction-manager>

or org.springframework.transaction.jta.JtaTransactionManager / org.springframework.transaction.jta.WebSphereUowTransactionManager but the data source still needs to be XA.

Answer 2

XADataSource defines a contract between a JDBC provider and the application server and can only be used in that context. The DataSource object that you get when looking up the data source via JNDI in your application will never implement the XADataSource interface, even if the underlying data source is configured to support XA.

If you want to use your own transaction manager, then you would also have to manage the data sources yourself. Note that personally I wouldn't do that and strongly advice to use WebSphere's transaction manager instead. The reason is that distributed transactions involve lots of subtleties (e.g. recovery and in-doubt transactions) and it is unlikely that setting up a transaction manager inside an application would achieve the same level of robustness as WebSphere's transaction manager.