Connections and transactions

 

All connection usage occurs within the scope of either a global transaction or a local transaction containment (LTC).

Connection behavior depends on your current operating scope. This article discusses some of the common characteristics you see when using connections in one of the transaction scopes of the product.

One can only share connections within a global transaction scope (assuming other sharing rules are met). However, you can serially reuse connections within an LTC scope. A a get/use/close connection pattern followed by another get/use/close (to the same data source or connection factory) enables you to reuse the same connection. See Unshareable and shareable connections for more details.

 

JDBC AutoCommit behavior

All JDBC connections, when first obtained through a getConnection call, have AutoCommit = TRUE by default.

  • If you operate within an LTC and have its resolution-control set to Application, then AutoCommit remains TRUE unless changed by the application.

  • If you operate within an LTC and have its resolution-control set to ContainerAtBoundary, then the application should not touch the AutoCommit setting. The WAS run time sets the AutoCommit value to FALSE before work begins, then commits or rolls back the work as appropriate at the end of the LTC scope.

  • If you use a connection within a global transaction, then regardless of the user changing the AutoCommit setting, upon first use of the connection to do work the database ignores the AutoCommit setting so that the transaction service that controls the commit and rollback processing can manage the transaction . After the transaction completes, the AutoCommit value returns to the value it had before the first use of the connection. So even if the AutoCommit value is set to TRUE before the connection is used in a global transaction, you need not set the value to FALSE since the value is ignored by the database. In this example, after the transaction completes, the AutoCommit value of the connection returns to TRUE.

  • If you use multiple distinct connections within a global transaction, all work is guaranteed to commit or roll back together. This is not the case for a local transaction containment LTC(scope). Within an LTC, work done on one connection commits or rolls back independently from work done on any other connection within the LTC.

 

One phase commit and two phase commit resources

One phase commit resources are such that work being done on a one phase connection cannot mix with other connections and ensure that the work done on all of the connections completes or fails atomically . The product does not allow more than one one-phase commit connection in a global transaction. Futhermore, it does not allow a one phase commit connection in a global transaction with one or more two phase commit connections. One can coordinate only multiple two phase commit connections within a global transaction.

Note that any time you do multiple getConnection calls using a resource reference that specifies res-sharing-scope=Unshareable , then you get multiple physical connections. This situation also occurs when res-sharing-scope=Shareable but the sharing rules are broken. In either case, if you run in a global transaction, ensure the resources involved are enabled for two phase commit (also sometimes referred to as JTA Enabled). Failure to do so results in an XAException that logs the following message: WTRN0063E: An illegal attempt to enlist a one phase capable resource with existing two phase capable resources has occurred.

Connection factory
Data sources
Unshareable and shareable connections
Connection handles
Using the transaction service