Transaction Processing

Yin and yang, life and death, Clark Kent and Superman. Some concepts are so intertwined that it's impossible to imagine one without the other. Transaction processing (TP) and relational databases make up another such pairing.

In theory, TP can happen without a relational database, but you wouldn't want to try it. And you could do a relational database without TP, but you would lose one of the benefits of having a relational database: the ability to update multiple tables to reflect the completion of a transaction.

Systems capable of doing TP must pass the ACID test: atomicity, consistency, isolation and durability. Transactions are atomic, meaning they either happen or not. If one account is debited, some other account must be credited.

The TP system must always be consistent with its own rules. No transaction can happen if errors are returned as the transaction is processed. For example, if a table that must be updated is on a hard drive that is inaccessible, the transaction fails.

 Transaction Monitors

The global coordinator shouldn’t be confused with the transaction monitor, also commonly known as transaction processing monitor software or the transaction server.

Transaction monitors are middleware programs that mediate between clients and servers. They optimize database performance by acting on behalf of the clients. Rather than have every client open a session with a server, the clients connect to a transaction monitor which queries the server through its own session. This relieves the server from the chore of handling numerous individual sessions.

First introduced in the 1970s for mainframe systems, transaction monitors were reborn in the late 1990s as software publishers rolled out new versions capable of handling online transaction processing systems providing services through Web servers.
— Pete Loshin
Isolating transactions means that other processes never see database tables in an intermediate state. They may get to see what the database looked like before or after the transaction, but not during. For example, anyone querying an airline reservation system for seating will see all seats not reserved at that moment. But if two people try booking the last seat on tonight's red-eye at the same time, only one can succeed.

Finally, transactions must be durable, meaning that once the last seat is reserved and the customer receives notification of the booking, that transaction is permanently recorded. Even if the system was hit by lightning after the transaction was complete, TP-capable systems would be able to retrieve it.

Two-Phase Commitment

Relational databases are sometimes defined as systems capable of doing transaction processing by virtue of their ACID-support. The "two-phase commit" (2PC) protocol is a defining characteristic as well as a key mechanism by which the transaction is enabled.

In the first phase of the 2PC, a global coordinator notifies all systems in the transaction that they should prepare to either commit the changes required by the transaction or roll back their tables to their previous state. The systems involved notify the global coordinator when they're prepared to commit the transaction or that they won't be able to commit the transaction. If a system doesn't respond, or responds with an error, the global coordinator will abort the transaction and notify systems to roll back the changes.

If all systems are go for the first phase, the coordinator notifies the systems to begin the commit phase by writing all changes and then notifying the coordinator. The transaction is completed only when all systems notify the coordinator that the changes have been committed; if any errors occur at this stage, the transaction will be canceled and all participants are required to roll back changes.

Transaction processing is a mature technology, as are the relational database and the transaction monitor. All were introduced in the 1960s and 1970s, as large data processing shops required mechanisms for reliably automating transactions. Over the decades, the cost of supporting TP has dropped to the point at which almost any business can apply it profitably.

Today, the problems of distributing transactions on the Web are similar to the problems of distributing them on systems with disparate data tables spanning multiple tape and disk drives. As a result, extending TP capabilities to the Internet is often as easy as building the interface and business logic for an application on an existing system. And e-commerce needs effective TP mechanisms. Without them, there would be no way to verify the transactions that form the basis for e-commerce.

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.
Show Comments