8.3 Transactions

Transactions are a part of everyday life. From a human perspective, a transaction is any exchange or transfer of goods, services, or funds. In a commercial transaction, either the consumer gets the goods and the seller gets the money, or the consumer does not get the goods and the seller does not get the money.

In the computing world, a transaction is a sequence of operations on a database. From the application developer's point of view, transactions are performed as an indivisible unit with a simple failure model. Transactions can have only one of two possible outcomes : success or failure. Transactions are guaranteed to have the following properties:

• Atomicity. The operations will be executed either completely or not at all.

• Consistency. The system moves from one self-consistent state to another.

• Isolation. The intermediate operations or states that occur during the transactions are not visible to other transactions that could be occurring simultaneously .

• Durability. The results of a transaction will not be lost in the event of a hardware or software failure.

These properties, often called ACID properties, ensure that transactions are complete, have consistent data, occur independently of concurrent transactions, and keep the results.

There are many types of transactions. The most common type is the flat transaction with or without save points. Other transaction types are not usually commercially supported and exist only in research products.

Flat Transactions

A flat transaction, the most basic type of transaction, is an atomic unit of work, managed by a single process. The transaction consists of one or more operations that can be performed by different processes or threads. These processes may be distributed across different platforms or servers. Once started, a flat transaction can only be committed or rolled back.

A simple example of a flat transaction is shown in Figure 8-5. In this example, issuing a Begin Transaction starts the transaction. Next , the necessary operations needed to complete the transaction are performed. Finally, if the operations were successful, the transaction is committed, using the Commit Transaction command; otherwise , the transaction is rolled back, using the Rollback Transaction command. Rollback means that the database is returned to its previous state, as if none of the operations within the transaction were executed. Figure 8-5 does not illustrate the results of possible failures.

Flat transactions can cause resources to be locked during the entire transaction. As a result, these transactions should be small and take minimal time to execute: typically, less than 2 to 3 seconds.

Flat Transactions with Save Points

Declared within the context of a transaction, save points are commands that save the progress of work, or operations performed, up to the location of the save point. If the transaction is aborted, it can be rolled back to the point of work performed just before the save point. Because save points allow a transaction to be broken up into smaller pieces, all operations between two save-point commands can be viewed as atomic. A common use of save points is to save work completed before beginning a set of operations, as shown in Figure 8-6. If a problem is detected during a transaction, the work can then be rolled back to the point just before the save point and retried in a different manner.

Chained Transactions

Chained transactions are similar to flat transactions with save points. In this case, work is divided into a set of smaller transactions, using commit points ”a chain operation ”that specify the boundary of a subtransaction. A commit point is used to both commit the last subtransaction and start the next subtransaction. Figure 8-7 shows a chained transaction used within a loop. The CommitPoint commits the last transaction and starts a new transaction. As shown in the example, if a problem is encountered , a Rollback is issued. These commands will roll back only to the last commit point. Thus, commit points can be used as a restarting point in the event of a failure. When using this model, a program is always executing within the scope of a transaction.

Figure 8-5 Flat transactions

 Begin Transaction  Operation 1  Operation 2  Operation 3  ...  Operation N If (Success) Commit Transaction Else Rollback Transaction 

Figure 8-6 Flat transactions with save point

 Begin Transaction  Operation 1  Op1Save=SaveWork()  Operation 2  Op2Save=SaveWork()  Operation 3  If (Operation 3 Error) Rollback(Op2Save){     Operation 4    } If (Operation 4 Error) Rollback Transaction Else Commit Transaction 

Figure 8-7 Chained transactions

 Set Chained Mode to true While (HaveWorkToDo) {  Do Sub-Transaction  If (Success) CommitPoint  Else Rollback } Set Chained Mode to false 

Closed Nested Transactions

A nested transaction allows you to define subtransactions within other transactions by breaking the transaction into a tree hierarchy of subtransactions, as shown in Figure 8-8. This type of transaction is also called a closed nested transaction. The leaf nodes of the tree are always flat transactions, whereas subtree nodes ”children ”contain a nested subtransaction. This model allows subtransactions within the subtree node or a subtransaction in a leaf node to commit or roll back, but the commit will not take effect unless the root node of the tree commits. Before a subtransaction commits, its updated data is visible only to its subtransactions. After a subtransaction commits, its updated data is made visible to other subtransactions that share the same parent. Rollbacks at a subtree node will cause any subtransactions under that node to also roll back.

Figure 8-8 Nested transactions

 Begin Transaction  Begin Transaction      Operation a1      Operation a2  Commit Transaction  Begin Transaction      Operation b1      Operation b2  Commit Transaction Commit Transaction 

This model supports top-level transactions with all the ACID properties. However, subtransactions in this model lack the durability property because of the behavior associated with rollbacks and commits with subtransactions. Subtransactions are not actually committed until the parent transaction commits.

The concept of nested transactions has been around since the early 1980s, but this transaction model has little commercial support. However, it is possible to simulate nested transactions by using save points, as shown in Table 8-3. As in this example, save points are used to roll back nested transactions from a given point on without affecting the transactions nested under different save points. A major advantage of nested transactions is that they offer a higher degree of concurrency than do other transactional models.

Open Nested Transactions

Open nested transactions are similar to closed nested transactions except that a commit operation in a subtransaction takes effect immediately, making the updated data visible before the parent node or root node commits. Additionally, rollbacks must be handled using a compensating transaction or a saga. A compensating transaction is a group of operations, or a transaction, used to undo the effect of a previously committed transaction. A saga is the capability to automatically determine and start a compensating transaction for every committed transaction in case a transactional failure occurs [Bernstein 97]. Sagas require an application programmer to write a compensating transaction for each transaction. This model is useful only if the subtransactions are fairly independent and can be rolled back, using a compensating transaction or a saga.

Table 8-3. Simulated Nested Transactions

Nested Transaction	Simulated Nested Transaction
Begin Transaction Operation a1 Operation a2 Begin Transaction Operation b1 Operation b2 Begin Transaction Operation c1 Operation c2 Commit Transaction Commit Transaction Commit Transaction	Begin Transaction Op1Save=SaveWork() Operation a1 Operation a2 Op2Save=SaveWork() Operation b1 Operation b2 Op3Save=SaveWork() Operation c1 Operation c2 Commit Transaction

As with closed nested transactions, this model has little commercial support. To date, the only commercial product that supports this transactional model is IBM Transarc's Encina TP monitor.

Multilevel Transactions

Multilevel transactions are similar to open nested transactions except that the tree of subtransactions must be balanced, that is, must all have the same depth. This balance allows the execution to be performed in layers . As with open nested transactions, a commit in subtransactions will take effect immediately, making the updated data visible, before the parent node or root node commits, and rollbacks must be accomplished by executing compensating subtransactions. The major advantages to this model are that it requires less locking and favors parallel execution.

Distributed-Access Transactions

Distributed-access transactions are more an attribute of a transaction or a subtransaction than a type of transaction. A distributed-access transaction occurs when a distributed application performs a transaction on a single database server. In cases of distributed access, the distributed application must maintain a transaction context, or the logical grouping of all the data update operations performed as part of a transaction. The transaction context is used to track and determine the work that must be committed or rolled back. This context must be propagated to all threads and applications participating in the transaction. An underlying transaction manager usually maintains the transaction context transparently .