Transaction processing

Transaction processing, minimally, is a way of carrying out client server interchanges such that they either run completely, with certainty the changes are committed to all relevant databases, or, if any part fails, the databases will be rolled back to the their state before the start of their transaction. During the processing, any records or other resources are locked so that multiple transaction threads do not try to update the same record. Airline reservations are a good example of a classic transaction processing application, in that no two clerks can try to sell the same seat at the same time. Another part of the example is that if a flight with several segments is being reserved, segment by segment, if the last segment has no seats, all of the preceding segment seats will be released.

From a technical standpoint, a properly defined transaction system, which will deal with multiple actions such as several airlines seat reservations, a hotel reservation, etc., has to have the four ACID properties discussed below. There is a different class of applications, defined for Web applications, that also are relevant to the idea of reliable transaction processing: that they are safe and idempotent. Specifics are discussed below, but think of two general properties; some transactions, such as checking an account balance are safe because they are read-only. Others have to be done once and only once, such as withdrawing cash from an account and adjusting the balance for each cash disbursement.

ACID properties

This is the class of database-oriented applications that must ensure consistency. Minimally, they have the property of atomicity:

"Transaction" is the term given to the programming model whereby computational work performed has atomic semantics. That is, either all work completes successfully and changes are made permanent (the transaction commits), or if any work is unsuccessful, changes are undone (the transaction aborts). The work comprising a transaction(unit of work), is defined by the application.

A practical way to see if an application follows transaction processing is that an Internet sales application complying with it would never, ever, order something twice if the user got impatient and hit "order" more than once.

Atomicity, which is achieved with resource locking and with various commit protocols that can roll back to the starting state, is not the only characteristic of transaction processing. Atomicity is the first letter of the ISO ISO/IEC 10026-1:1992 Section 4 mnemonic usually used to characterize transaction processing: ACID:

• Atomicity
• Consistency: whatever processing done leaves all affected databases in a legal state when the transaction starts and ends. Consistency sometimes overlaps security policy, as, for example, that all of a given customer's accounts must have a positive balance before any of a list of transactions can even start.
• Isolation means that no operation outside the transaction can ever see the data in an intermediate state; a money trader can see the transferred funds on one account or the other, but never on both -- even if he ran his query while the transfer was still being processed. More formally, isolation means the transaction history is serializable.
• Durability refers to the guarantee that once the user has been notified of success, the transaction will persist, and not be undone. Transactions must be strictly fault tolerant; many stock and money trading applications not only keep logs and multiple coies of disks, but may run the transaction in parallem on a hot standby computer. A transaction is complete only when it is in a trusted and permanent log.

Safe and idempotent

According to the W3C Consortium and the Internet Engineering Task Force, a safe transaction takes no action other than reading a file, webpage, etc. and conveying its information to the end user. If that retrieveal operation has side effects, "the user did not request the side-effects, so therefore cannot be held accountable for them."

An idempotent transaction does change resources, but if it obeys the idempotent rule, the same effect will be produced by 1, or any large number, of copies of the same transaction. The classic example of a non-idempotent transaction is an online sale for one product, where hitting the "submit" link multiple times causes multiple charges to a credit card, although the context should show that only one order for one item is actually being placed.