my dog learned polymorphism*
The moose likes JDBC and the fly likes Performance - XA Vs Non XA Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Databases » JDBC
Bookmark "Performance - XA Vs Non XA" Watch "Performance - XA Vs Non XA" New topic
Author

Performance - XA Vs Non XA

Deepak Bala
Bartender

Joined: Feb 24, 2006
Posts: 6661
    
    5

Is a non XA JDBC driver faster/more efficient than a XA JDBC driver ?

I am considering shifting some data sources to use XA drivers. They participate in cross database transactions. However the part of code where they participate in cross database transactions is not very large (a few scenarios only). My question is, would making this data source use a XA driver all the time bring down the performance ? If so are there any studies or recommendations to back that ?

My other option is to split the data source to XA and non XA types if performance is of concern


SCJP 6 articles - SCJP 5/6 mock exams - More SCJP Mocks
jimmy jones
Greenhorn

Joined: Aug 30, 2007
Posts: 1
There has to be some overhead to using an XA driver rather than a non XA driver. What database are you using?

I have found that changing to SQL Servers XA driver to to the had a very bad impact in performance, it caused a significant increase in database locking under load. Fortunately I was using Weblogic which allows you to emulate XA for 1 non XA datasource so there was no need to use the SQL Server XA driver, it might be worth checking your application servers documentation for a similar feature.


<a href="http://javamix.co.uk" target="_blank" rel="nofollow">http://javamix.co.uk</A> the only bookmark you need.
Deepak Bala
Bartender

Joined: Feb 24, 2006
Posts: 6661
    
    5

Originally posted by jimmy jones:
There has to be some overhead to using an XA driver rather than a non XA driver. What database are you using?

I have found that changing to SQL Servers XA driver to to the had a very bad impact in performance, it caused a significant increase in database locking under load. Fortunately I was using Weblogic which allows you to emulate XA for 1 non XA datasource so there was no need to use the SQL Server XA driver, it might be worth checking your application servers documentation for a similar feature.


I am using weblogic 9. However the emulate 2 phase commit option is kinda like a dummy implementation of a XA resource. In other words if your resource fails a transaction it will still say that it is prepared to commit and the other parties in the transaction will commit as well. It could lead to some inconsistencies in the application.

I cannot use the emulate option here since I am opening a transaction and allowing it to span across two databases. If I emulate the 2PC I get an error that says I am not allowed to make two non XA resource take part in a transaction involving two different databases. I initially thought that the emulate option would bypass any such errors. Oh well. I guess I ll split the datasource to XA and non XA types to avoid any performance problems.

I am using Sybase by the way
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Performance - XA Vs Non XA
 
Similar Threads
cannot add non-XA Resource to global JTS transaction
How to commit JDBC prior to JMS in a Transaction
Transaction: Spring2.x + Hibernate3.0 + Jboss + Multiple Databases
Implementation of XA Transaction without App.Server?
Usage of XA vs Non-XA Driver for Transactions