Technical data

16 Managing JDBC Connectivity
16-22 Administration Guide
Heuristic Completions and Data Inconsistency
When Enable Two-Phase Commit is selected for a non-XA resource,
(
enableTwoPhaseCommit = true), the prepare phase of the transaction for the
non-XA resource always succeeds. Therefore, the non-XA resource does not truly
participate in the two-phase commit (2PC) protocol and is susceptible to failures. If a
failure occurs in the non-XA resource after the prepare phase, the non-XA resource is
likely to roll back the transaction while XA transaction participants will commit the
transaction, resulting in a heuristic completion and data inconsistencies.
Because of the data integrity risks, the Enable Two-Phase Commit option should only
be used in applications that can tolerate heuristic conditions.
Cannot Recover Pending Transactions
Because a non-XA driver manipulates local database transactions only, there is no
concept of a transaction pending state in the database with regard to an external
transaction manager. When
XAResource.recover() is called on the non-XA
resource, it always returns an empty set of Xids (transaction IDs), even though there
may be transactions that need to be committed or rolled back. Therefore, applications
that use a non-XA resource in a global transaction cannot recover from a system failure
and maintain data integrity.
Possible Performance Loss with Non-XA Resources in Multi-Server Configurations
Because WebLogic Server relies on the database local transaction associated with a
particular JDBC connection to support non-XA resource participation in a global
transaction, when the same JDBC data source is accessed by an application with a
global transaction context on multiple WebLogic Server instances, the JTS driver will
always route JDBC operations to the first connection established by the application in
the transaction. For example, if an application starts a transaction on one server,
accesses a non-XA JDBC resource, then makes a remote method invocation (RMI) call
to another server and accesses a data source that uses the same underlying JDBC
driver, the JTS driver recognizes that the resource has a connection associated with the
transaction on another server and sets up an RMI redirection to the actual connection
on the first server. All operations on the connection are made on the one connection
that was established on the first server. This behavior can result in a performance loss
due to the overhead associated with setting up these remote connections and making
the RMI calls to the one physical connection.