A transaction is a series of discreet actions in an application that must all complete successfully or else all the changes in each action are backed out. For example, to transfer funds from a checking account to a savings account is a transaction with the following steps:
Check to see if the checking account has enough money to cover the transfer.
If there’s enough money in the checking account debit the amount from the checking account.
Credit the money to the savings account.
Record the transfer to the checking account log.
Record the transfer to the savings account log.
If any of these steps fails, all changes from the preceding steps must be backed out, and the checking account and savings account must be in the same state as they were before the transaction started. This event is called a rollback. If all the steps complete successfully, the transaction is in a committed state. Transactions end in either a commit or a rollback.
Transaction processing involves the following five participants:
Each of these entities contribute to reliable transaction processing by implementing the different APIs and functionalities, discussed below:
The Transaction Manager provides the services and management functions required to support transaction demarcation, transactional resource management, synchronization, and transaction context propagation.
The Enterprise Server provides the infrastructure required to support the application runtime environment that includes transaction state management.
The Resource Manager (through a resource adapter) provides the application access to resources. The resource manager participates in distributed transactions by implementing a transaction resource interface used by the transaction manager to communicate transaction association, transaction completion and recovery work. An example of such a resource manager is a relational database server.
A Resource Adapter is a system level software library that is used by the application server or client to connect to a Resource Manager. A Resource Adapter is typically specific to a Resource Manager. It is available as a library and is used within the address space of the client using it. An example of such a resource adapter is a JDBC driver.
A Transactional User Application developed to operate in an application server environment looks up transactional data sources and, optionally, the transaction manager, using JNDI. The application may use declarative transaction attribute settings for enterprise beans or explicit programmatic transaction demarcation.
The Enterprise Server provides workarounds for some known issues with the recovery implementations of the following JDBC drivers. These workarounds are used unless explicitly disabled.
Oracle thin driver - The XAResource.recover method repeatedly returns the same set of in-doubt Xids regardless of the input flag. According to the XA specifications, the Transaction Manager initially calls this method with TMSTARTSCAN and then with TMNOFLAGS repeatedly until no Xids are returned. The XAResource.commit method also has some issues.
To disable the Enterprise Server workaround, set the oracle-xa-recovery-workaround property value to false. For details about how to set a property, see To configure how the Enterprise Server recovers from transactions.
These workarounds do not imply support for any particular JDBC driver.