mis lecture 11

8/6/2019 MIS Lecture 11

http://slidepdf.com/reader/full/mis-lecture-11 1/5

Management Information Systems 2010/2011 Lecture … (11)

88

Traditional Transaction Models

As the transaction environment evolves from the centralized environment to

distributed and mobile environments, the properties and the structure of

transactions change. However, several basic transaction models are indispensable.

In this section, we will review the following transaction models:

1. Flat transaction model.

2. Nested transaction model.

3. Multilevel transaction model.

4. Sagas transaction model.

5. Split and Join transaction model.

Flat Transaction Model

The flat transaction model presents the simplest transaction structure that fully

meets the TPS properties. Figure 22 illustrates the structure of a flat transaction.

The building block of a flat transaction, between Begin and Commit /Abort

operations, contains all the database operations that are tightly coupled together as

one atomic database operation. The flat transaction begins at one consistent

database state, and either ends in another consistent state, i.e., the transaction

commits, or remains in the same consistent state, i.e., the transaction aborts.

FIGURE 22: Flat Transaction Model




89

Nested Transaction Model

The nested transaction model defines the concepts and the mechanisms for

breaking up the large building block of a flat transaction into a set of smaller

transactions, called sub-transactions. Thus, the nested transaction model has a

hierarchical tree structure that includes a top-level transaction and a set of sub-

transactions (either parent or children transactions). Sub-transactions at the leaf

level of the transaction tree are flat transactions.

FIGURE 23: Nested Transaction Model

Multilevel Transaction Model

The multilevel transaction model is looser than the nested transaction model

in terms of the relationship between parent and children transactions.

Sub-transactions in the multilevel transaction can commit or abort

independently of their parents. This is supported by the concepts of compensating

transactions. We will briefly discuss the concept of compensating transactions ,

and its opposed contingency transactions (see Figure 24).




90

• Compensating Transactions are designed to undo the effect of the original

transactions that have aborted. The compensating transactions are triggered and

started when the original transactions fail. Otherwise, the compensating

transactions are not initiated. Once a compensating transaction has started, it

must commit. In other words, the compensating transactions can not abort. If a

compensating transaction fails, it will be restarted.

• Contingency Transactions are designed to replace the task of the original

transactions that have failed. Contingency transactions are also triggered by the

failures of the original transactions. Note that it is not always possible to

specify the compensating or contingency transactions for an original

transaction.

FIGURE 24: Compensating and Contingency Transactions

Sagas Transaction Model

The Sagas transaction model also makes use of the concept of compensating

transactions to support transactions whose execution time is long. A Sagas

transaction consists of a consecutive chain of flat transactions Si that can commit

independently. For each flat transaction Si, there is a compensating transaction CPi




91

that will undo the effect of the transaction Si if the transaction Si aborts. A

compensating transaction CPi in the Sagas chain is triggered by the associated

transaction Si or the compensating transaction CPi+1. If the Sagas transaction

commits, no compensating transaction CPi is initiated (see Figure 25), otherwise

the chain of compensating transactions is triggered (see Figure 26).

FIGURE 25: A successful Sagas

FIGURE 26: An unsuccessful Sagas

Split and Join Transaction Model

The Split and Join transaction model was proposed to support the open ended

activities that associate with transactions. The Split and Join transaction model

focuses on activities that have uncertain duration, uncertain developments, and are

interactive with other concurrent activities. The main idea is to divide an on- going

transaction into two or more serializable transactions, and to merge the results of




92

several transactions together as one atomic unit. In other words, the Split and Join

transaction model supports reorganizing the structure of transactions (as illustrated

in Figure 27).

FIGURE 27: Split and Join Transaction Model

mis lecture 11

Documents