Transaction Processing

Computerworld - 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 [Technology QuickStudy, Jan. 8] make up another such pairing.

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 [Technology, QuickStudy, May 17, 1999]. 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

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.

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.