Can anybody please tell me the definition for XA datasource and NonXA datasource?What is XA stands for?
Where can I find documentation/tutorial to understand XA/NonXA more?
- read the JDBC spec by Sean Sullivan on September 11 2003 13:03 EDT
- XA and NonXA datasource by Mike Spille on September 11 2003 17:28 EDT
- XA and NonXA datasource by Huy Nguyen on September 11 2003 20:56 EDT
- Thanks by Hatem El-Kazak on February 05 2006 10:30 EST
- Re: XA and NonXA datasource by Tenzing N Wangdi on July 13 2006 04:10 EDT
- Nicely and concisely explained, Mike. by Stephen Zhang on July 01 2007 20:57 EDT
- thanks for the valuable information by Mukthiyar ahmed on February 05 2009 02:36 EST
- XA and NonXA datasource by John Sanders on December 02 2011 04:06 EST
- Awesome mike. Perfact explaination.... by Yashendra Singh on June 01 2012 16:24 EDT
- XA and NonXA datasource by Jayakumar Ramaswamy on April 15 2013 01:59 EDT
- Mike , Thank you for a wonderfurl explanation ! by Sandeep Chatterji on June 24 2013 14:39 EDT
- XA and NonXA datasource by Ananta Vijay Guha on January 20 2005 06:22 EST
- XA and NonXA datasource by Shomaila Kausar on December 05 2005 09:54 EST
- very good explanation by Samir Sahu on December 10 2007 02:29 EST
- User XA or NonXA DataSource, 1 phase or 2 phase commit? by Pierre Yin on September 02 2010 08:59 EDT
- WebSphereExtendedJTATransactionLookup Vs WebSphereExtendedJtaPlat by Suresh Mani on November 27 2013 04:03 EST
read the JDBC specification
As for what they mean: XA are for distributed transactions (as per the Open Group specificitions) and non-XA are not (transactions must be single-database).
An XA transaction, in the most general terms, is a "global transaction" that may span multiple resources. A non-XA transaction always involves just one resource.
An XA transaction involves a coordinating transaction manager, with one or more databases (or other resources, like JMS) all involved in a single global transaction. Non-XA transactions have no transaction coordinator, and a single resource is doing all its transaction work itself (this is sometimes called local transactions).
XA transactions come from the X/Open group specification on distributed, global transactions. JTA includes the X/Open XA spec, in modified form.
Most stuff in the world is non-XA - a Servlet or EJB or plain old JDBC in a Java application talking to a single database. XA gets involved when you want to work with multiple resources - 2 or more databases, a database and a JMS connection, all of those plus maybe a JCA resource - all in a single transaction. In this scenario, you'll have an app server like Websphere or Weblogic or JBoss acting as the Transaction Manager, and your various resources (Oracle, Sybase, IBM MQ JMS, SAP, whatever) acting as transaction resources. Your code can then update/delete/publish/whatever across the many resources. When you say "commit", the results are commited across all of the resources. When you say "rollback", _everything_ is rolled back across all resources.
The Transaction Manager coordinates all of this through a protocol called Two Phase Commit (2PC). This protocol also has to be supported by the individual resources.
In terms of datasources, an XA datasource is a data source that can participate in an XA global transaction. A non-XA datasource generally can't participate in a global transaction (sort of - some people implement what's called a "last participant" optimization that can let you do this for exactly one non-XA item).
For more details - see the JTA pages on java.sun.com. Look at the XAResource and Xid interfaces in JTA. See the X/Open XA Distributed Transaction specification. Do a google source on "Java JTA XA transaction".
very through and well explanation
Same here, Thank you very much Mike!
Nice write up Mike :)
simple yet very informative. thanks alot
X/Open specification for transaction management has in it 2 specifications XA is a specification between the transaction manager and resource manager and TX is the specification for Applications and Transaction manager interaction.
All XA-compliant transactions are distributed transactions; XA supports both single-phase and two-phase commit
Hi Vrushali - I understand XA doesn't support single-phase commit. If otherwise, can you please explain more how the protocol will work in a distributed txn.
The Explanation is too good. I really did not understand Whats an XA was? Thanks to MIKE.
Good job,Mike. Your explanation is both nicely and concisely said without a leaking of technical insight. Can definitely be used to present to both mangers or developers without too much tweaking.
Hi Thanks for the clarification in the difference between the XA and Non XA
Excellent Mike....Very good explanation..
Please post the source when you quote information...
I did not understand your message.
The blog you linked is actually quoting Mike's post.
Thanks Mike, Awesome. Perfact explaination....
Good explanation Mike. Easy to get it.
Great explaining Mike. Thanks a lot.
I think Xa stand for extended architecture...
Mike, the explanation is very good.
I need to migrate an old EJB application from WebLogic 8/Oracle 9 to WebLogic 10.3/Oracle 11g.
Within the OnMessage method of a MDB with CMT configured, we need to access two shcemas within a single Oracle database, plus to publish a JMS message to a queue that has been configured to perisis to a JDBC data store in the same Oracle database. Now in total, 3 datasources are being used.
My questions for the gurus
1. Do I need to use XA datasource? My assumption is yes because I need to use JDBC connection and send JMS message within the same OnMessage() method.
2. Do I need to use 2-phase commit? I assumed yes as this is all the purpose that XA datasourde is used.
3. Do I still need XA and 2 phase commit if I do not use JMS in the OnMessage() method? In this case, I only have two connections going to the same database. I understand XA is required when we need to access two "resources" according to the specification, however, should I consider the 2 JDBC connections going to the same database as 1 resource or 2 resources. I am trying to map the spedification to a real life case.
We are upgrading app server from WebSphere6.1 to WebSphere8, we are using the 2 phase commit protocol , resources (db as DB2 and plus to publish messages to the Topic) and upgrading hibernate 4.1.8. with WebSphere6.1 we are using the below hibernate.transaction class hibernate.transaction.manager_lookup_class=org.hibernate.transaction.WebSphereExtendedJTATransactionLookup hibernate.transaction.factory_class=org.hibernate.transaction.JTATransactionFactory now with WebSphere8 using the hibernate.transaction class as hibernate.transaction.jta.platform=org.hibernate.service.jta.platform.internal.WebSphereExtendedJtaPlatform with this WebSphereExtendedJtaPlatform, we are getting the rollback error from Topic and getting commit the changes to DB2. seems like the 2 phase commit is not working. MQ is rolling back the transaction believing that it is a local transaction instead of a global XA transaction. need your inputs on this issue. Curiously awaiting your response! Appreciate any of your efforts in this regard! Thanks, Suresh