All connection usage occurs within the scope of either
a global transaction or a local transaction containment (LTC) boundary.
Each transaction type places different requirements on connections
and impacts connection settings differently.
Connection sharing and reuse
You
can share connections within a global transaction scope (assuming
other sharing rules are met). You can also share connections within
a shareable LTC. You can serially reuse connections within
an LTC scope. A get/use/close connection pattern followed by another
instance of get/use/close (to the same data source or connection factory)
enables you to reuse the same connection. See the topic, Unshareable
and shareable connections for more details.
JDBC AutoCommit behavior
All JDBC connections,
when first obtained through a getConnection() call, contain the setting
AutoCommit = TRUE by default. However, different transaction scope
and settings can result in changing, or simply overriding, the AutoCommit
value.
- If you operate within an LTC and have its resolution-control set
to Application, AutoCommit remains TRUE unless changed
by the application.
- If you operate within an LTC and have its resolution-control set
to ContainerAtBoundary, the application must not touch
the AutoCommit setting. TheWebSphere® Application Server 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, the database
ignores the AutoCommit setting so that the transaction service that
controls the commit and rollback processing can manage the transaction.
This action takes place upon first use of the connection to do work,
regardless of the user changing the AutoCommit setting. 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 because 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 connections
The
type and number of resource managers, such as a database server, that
must be accessed by an application often determines the application
transaction requirements. Consequently each type of resource manager
places different requirements on connection behavior.
- A two-phase commit resource manager can support two-phase coordination
of a transaction. That support is necessary for transactions that
involve other resource managers; these transactions are global transactions.
See the topic, Transaction support in WebSphere Application Server for further explanation.
- A one-phase commit resource manager supports only one-phase transactions,
or LTC transactions, in which that resource is the sole participating
datastore. See the topic, Transaction support in WebSphere Application Server for further explanation.
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. You can coordinate
only multiple two-phase commit connections within a global transaction.
WebSphere Application Server provides last
participant support, which enables a single one-phase commit resource
to participate in a global transaction with one or more two-phase
commit resources.
Note that any time that you do multiple getConnection()
calls using a resource reference that specifies res-sharing-scope=Unshareable
, 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 XA exception
that logs the following message:
WTRN0063E: An illegal attempt to enlist a one phase capable resource with existing two phase capable
resources has occurred.