Migrating from Non-XA driver type to XA Driver in Weblogic 11g

Question

I have two data sources created in weblogic 11g which were configured in following manner and we are using this configuration since our application started supporting weblogic as application server that's Weblogic 9i.
Database A: Participates in Global Transaction
Driver Type: Oracle Thin Driver non-XA
Support Global Transaction option is disabled for this data source.
Database B: Participates in Global Transaction
Driver Type: Oracle Thin Driver non-XA
Support Global Transaction option is enabled for this data source with One Phase Commit enabled.
If we use this configuration our application run just fine without any issues.
Now we have a requirement of adding another data source which participates in global transactions.When I create this data source with following settings,
Driver Type: Oracle Thin Driver non-XA
Support Global Transaction option is enabled for this data source with One Phase Commit enabled.
This results in error (which was expected) "
"*SQL ERROR: Connection has already been created in this tx context for pool named CMDEMO. Illegal attempt to create connection from another pool: EXPDB*"
and even when I enable "Support Global Transaction" option with LLR or Emulate Two phase Commit option this results is error,
"*Database Error: Unexpected exception in Non XA Resource enlistment. Resource=JDBC LLR, pool=EXPDB, table=WL_LLR_ADMINSERVER Cannot enlist more*
than one Non XA Resource. Attempt to enlist 'WL_JDBC_LLR_POOL.EXPDB' when 'WL_JDBC_LLR_POOL.CMDEMO' is already enlisted."
Now we are planning to move to "Oracle Thin Driver XA" driver type for all the three data sources.I tested this config. and all global transaction are getting executed perfectly.
But before we adopt this change,I just wanted to check what all are the limitations of using XA driver or any potential issues that needs to be tested. I explored about this and came to know that XA comes with performance overhead ,frequent database locking with SQL Server driver, and some conflicts with multibyte character sets etc.
Can someone please provide some input on how to tread ahead and what all things needs to tested.

Answer 1

How are you using these connection pools in your application?
Do you have different EJB's, which have the default transaction attribute configured (@TransactionAttribute(TransactionAttributeType.REQUIRED)),
and are calling each other?
If one EJB is using connection pool A and the other is using connection pool B, you get in trouble because the transaction is already
started by EJBone and is propagated to EJBother. In this case you can use @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW).
Now a new transaction is started for EJBother.
Some information about XA
The primary difference is that data sources that support global transactions are JTA transaction-aware.
Realize that JTA transactions do not necessarily mean XA transactions and two-phase commits (2PC). JTA
transactions also allow two independently written components that modify the same database to participate
in a transaction without having to know about each other. Non-XA database transactions require the
use of a single database connection to provide the proper transactional semantics. If you choose not to
use the Supports Global Transactions option, you need to write your application components in such
a way that they get a database connection from the pool at the start of every transaction and pass that
connection around to every component that participates in the transaction. This is clearly not desirable
and not even possible with certain types of components (for example, JPA managed entities).
A data source that supports global transactions will make sure that your components participating in a
JTA transaction get the proper transactional semantics whether or not they are using XA transactions.
When not using XA transactions, the data source accomplishes this by associating a database connection
with a JTA transaction context. Every time a component asks for a database connection using the data
source that supports global transactions, WebLogic Server will check to see if the current transaction
already has a database connection, and if so, it will always hand back the same underlying database connection.
This allows non-XA transactions to maintain the proper database semantic guarantees without
having to worry about what database connection to use and what the transactional boundaries are for
the application.