Website Design Tips - Hypergurl

1 | 2 | 3 | 4 | 5 | 6 | 7

This article was written by Tanya Puntti for Database Application Development - Central Queensland University.

Introduction

The purpose of this report is to discuss transaction processing in large database systems and specifically the role of transaction processing monitors. Firstly the report discusses what a database transaction is. It then goes on to discuss what properties transactions should follow to ensure reliability. Transaction processing monitors are examined including the purpose they serve and the architecture of such a system. Additionally, it studies three popular monitor products; Tuxedo from BEA Systems, Microsoft Transaction Server and CICS from IBM, including their features and benefits. Furthermore, the criteria enterprise should use when choosing between transaction processing monitors is considered as well as whether all applications that involve transaction processing should use such a system.

What is a database transaction?

A database transaction is ‘a unit of work that is performed against a database’ (Plew & Stephens 2003). In other words, any single operation made on the databases data is called a transaction. For example, when a customer purchases a holiday from an online tour agency it may require many related bookings from airlines, hotels and car rental companies and so forth. From the customer’s viewpoint, the entire holiday package is one purchase. On the other hand, from the viewpoint of the ordering system, many transactions are executed. One transaction in the least is needed for the airline reservation, one for the each hotel booking and one for each car rental. Furthermore, transactions are also needed for printing each ticket and finalising the invoice. As demonstrated, each transaction is independent from all others.

ACID

To ensure transactions are processed reliably, they should follow the ACID property (Begg & Connolly 2002, p.553). In reference to databases, ACID stands for Atomicity, Consistency, Isolation, and Durability.

Atomicity guarantees that all of the tasks of a transaction are performed or none of them are. For example, completing a holiday package from an online tour agency can fail for a multitude of reasons. There may be website or server problems, or the customer may not have enough credit in their bank account to pay for the whole package. Atomicity guarantees that one part of the package won't be debited if the others are not debited as well.

Consistency refers to the database being in a legal state when the transaction begins and when it ends. Consistency ensures a transaction can't break the rules or integrity constraints of the database. For example, suppose a specific transaction is intended to transfer money from the customer’s bank account to that of a hotel owner and there is an error in the transaction logic. This error debits the customer’s bank account but credits the airline instead of the hotel owner. The database is then said to be in an inconsistent state. Consistency ensures that any transaction in an inconsistent state will be aborted.

Isolation refers to the ability of the application to make operations in a transaction appear isolated from all other operations. For example, a hotel company should be able to see specific hotel reservations made by the customer from the tour agency. However, they should not be able to see the customer’s airline reservation or car rental details.

Durability refers to the guarantee that once the user has been notified of success, the transaction will not be undone. For example, if a tour package has been paid for and tickets printed out by the customer, a system failure from the agencies end should not affect the customer’s holiday. Developers often ensure durability by having all transactions written to a log file that can be used to backup the system in case of failure. Hence, developers design systems to commit to a transaction only after it is safely in the log.

Databases and transaction processing monitors ensure ACID properties through the use of locks, logs and two-phase commit as well as numerous other techniques (Kroenke 2004).

Continue .....