Does anyone know what these Oracle AQ JMS XA properties do?

I'm using Oracle Advanced Queues via JMS from within Websphere App Server.

Does anyone know what effect the following two properties have:-

 - oracle.jms.useEmulatedXA
 - oracle.jms.useNativeXA

I have seen mentioned in some blogs and quick start guides, usually in sentences along the lines of "Add -Doracle.jms.useEmulatedXA=false -Doracle.jms.useNativeXA=true to the JAVA_PROPERTIES variable", without any explanation as to what they do:-

e.g.

• http://biemond.blogspot.com/20开发者_开发知识库08/11/using-aq-in-weblogic-103.html
• http://sqltech.cl/doc/oas10gR31/integrate.1013/b28994/adptr_aq.htm#CHDEADFB

I'm curious as to what these two properties actually do, and what the implications of setting them are, even though they don't seem to have any affect on our app regardless of whether we set them or not.

Googling hasn't given any answers, does anyone have any clue what they actually do?

Hopefully this link will explain things in detail: http://bit.ly/bsl9Un The relevant bits include the following...

Emulated data sources are data sources that emulate the XA protocol for JTA transactions. Emulated data sources offer OC4J caching, pooling, and Oracle JDBC extensions for Oracle data sources. Historically, emulated data sources were necessary because many JDBC drivers did not provide XA capabilities. Today even though most JDBC drivers do provide XA capabilities, there are still cases in which emulated XA is preferred (such as transactions that do not require two-phase commit.)

Connections obtained from emulated data sources are extremely fast, because the connections emulate the XA API without providing full XA global transactional support. In particular, emulated data sources do not support two-phase commit. Oracle recommends that you use emulated data sources for local transactions, or when your application uses global transactions without requiring two-phase commit.

And...

Nonemulated data sources provide full (nonemulated) JTA services, including two-phase commit capabilities for global transactions. Nonemulated data sources offer pooling, caching, distributed transactions capabilities, and vendor JDBC extensions (currently, only Oracle JDBC extensions). For information on the limitations of two-phase commit, see Chapter 7, "Java Transaction API".

Oracle recommends that you use nonemulated data sources for distributed database communications, recovery, and reliability. Nonemulated data sources share physical connections for logical connections to the same database for the same user.

So what is happening when you set emulated XA is that your app thinks it is getting XA but the calls are optimized or translated to single-phase commit. When you specify non-emulated XA then you are getting the full XA functionality. Either way, the app is blissfully unaware.