Introduction to Transactions

Today transactions play a very important role in almost all business sectors (finance, banking, and so on). A transaction encapsulates a set of operations that is either successfully completed or not completed at all.

Let's look at a real-life example of transaction handling. When a customer goes to an ATM to make a transaction, there are a series of operations performed after the customer inserts an ATM card into the machine's card reader slot (see Figure 14.1). They are as follows:

1. Customer selects the type of operation (withdrawal, deposit, and so on).

2. Customer enters appropriate details, like customer card number and PIN, which are sent to the bank via the ATM for validation.

3. Bank validates the details and completes the operation.

4. Customer is informed of the successful completion of the operation and is asked if he wants to perform another operation.

Figure 14.1. An ATM transaction.

These steps are the elements of a successful transaction, where all the steps are effectively completed.

Now let's take a scenario where the customer wants to make a cash withdrawal but the ATM is out of cash. Although the bank may approve the transaction, the customer will not receive the money. The ideal situation would be that no amount is debited from his bank account because the ATM had a problem with the cash withdrawal transaction. In this case, all the operations would be rolled back and a screen would be displayed informing the customer of the reason for the failure of the transaction. Then the customer would be offered the opportunity to do any other transactions (deposit, withdrawal, and so on). This is an example of the transaction rollback operation.

Transactions play an important role in enterprise applications, where there are concurrent accesses to distributed data. In order to maintain data integrity, it may be required to group the set of operations as a single unit of work. In this unit of work, all the operations should succeed, fail, or recover together.

Distributed Transactions

A distributed transaction involves components that are deployed on multiple servers yet are part of the same transaction. Each server has its own transaction manager, which communicates with one or more resource managers. Since transaction processing spans multiple components deployed on numerous servers, the transaction manager is responsible for managing the transaction.

Two-Phase Commit

In a two-phase commit, the transaction manager ensures that all resources enlisted for a transaction are either committed or rolled back by the resource manager. Generally, when a client application calls for committing the transaction, the following phases are involved:

• Phase 1: The transaction manager issues a prepare request to all the resources that are a part of the transaction. If any resource decides to abort, it can do so, and the transaction will be canceled.

• Phase 2: At this point it is understood that all the resources are ready to commit, so the transaction manager issues a "commit" request to the resource manager, which in turn instructs the resources to commit.