Overview of transactions

A transaction is a set of operations performed on data that must be run as a single unit. The operations change data from one state to another, while the transaction monitor ensures the state change is consistent. This set of operations is an indivisible unit of work. In some contexts, a transaction is referred to as a logical unit of work (LUW). A transaction is a tool for distributed systems programming that simplifies failure scenarios.

Transactions provide the A.C.I.D. properties:

As an example, consider a transaction that transfers money from one account to another. Such a transfer means that money is deducted from one account and deposited in the other. Withdrawing the money from one account and depositing it in the other account are two parts of an atomic transaction: if both cannot be completed, neither must happen. Consistency is a function of the application; if money is to be transferred from one account to another, the application must subtract the same amount of money from one account that it adds to the other account. If multiple requests are processed against an account at the same time, they must be isolated so that only a single transaction can affect the account at one time. If the bank's central computer fails just after the transfer, the correct balance must still be shown when the system becomes available again: the change must be durable.

Transactions can be completed in one of two ways: they can commit or roll back. A successful transaction is said to "commit." An unsuccessful transaction is said to "roll back." Any data modifications made by a rolled back transaction must be completely undone. In the money transfer example, if money is withdrawn from one account but a failure prevents the money from being deposited in the other account, any changes made to the first account must be completely undone. The next time any source queries the account balance, the correct balance must be shown.

Distributed transactions

The scope of a distributed, or global, transaction can include multiple processes that are potentially distributed across multiple servers, and can include interactions with many data sources. To synchronize related pieces of work that are taking place in different processes, application servers which handle distributed transactions use a two-phase commit protocol and transaction log files. For more information, see Distributed transactions and the two-phase commit protocol and Transaction log files.

Throughout a transaction's lifetime, a series of transaction state changes occur. For more information about transaction states, see Transaction states.

Transaction timeouts

Because timeouts associated with transactions prevent any one transaction from holding server resources for too long, administrators rarely need to intervene in server transactions.

For example, consider two transactions whose simultaneous processing results in competition among two application server threads for the same resource. In this case, a thread acting on behalf of one transaction holds a lock on a resource, while another thread, acting on behalf of the other transaction, requests the same resource. The lock modes conflict, and the thread requesting the second lock waits until the other thread completes its work and releases the lock. In the event the other thread does complete within the timeout period, the requesting thread times out and the application server cancels that transaction. For more information, see Transaction isolation and locking considerations.

Transactions that have been inactive for a duration longer than the transaction inactivity timeout value for the application server are rolled back (or canceled). These timeout values can be set by accessing your data source properties in the Administrative Console. Additionally, the application server rolls back those active-state transactions whose life span has exceeded a transaction timeout value. Nevertheless, the processing of a transaction can be suspended (or hung) indefinitely if, for example, the transaction is in the prepared state but the application server coordinating the distributed transaction is unreachable.

If the ability of your server to process other transactions is constrained by a suspended transaction (perhaps because data access locks are being held on behalf of the hung transaction), you might need to intervene by forcing an outcome. For more information, see Force translation outcomes in the Administration topic.

An unprepared transaction can be canceled at any time. Unprepared transaction states include active-state and preparing-state. Canceling an unprepared transaction does not affect the consistency of data because no portion of the transaction has attempted to commit. If you cancel an unprepared transaction, any work that was completed on behalf of the transaction is rolled back.

With transactions that have already been prepared, any action that you take is more significant. It is best to allow the system to resolve the transaction. Forcing an outcome can be required when a transaction cannot be completed. Note, however, that you can introduce inconsistencies into server data by forcing a transaction to the wrong outcome.