Transaction processing system

History

The first transaction processing system was SABRE, made by IBM for American Airlines, which became operational in 1970. Designed to process up to 83,000 transactions a day, the system ran on two IBM 7090 computers. SABRE was migrated to IBM System/360 computers in 1972, and became an IBM product first as Airline control Program (ACP) and later as Transaction Processing Facility (TPF). In addition to airlines TPF is used by large banks, credit card companies, and hotel chains.

The Hewlett-Packard NonStop system (formerly Tandem NonStop) was a hardware and software system designed for Online Transaction Processing (OLTP) introduced in 1976. The systems were designed for transaction processing and provided an extreme level of availability and data integrity.

List of transaction processing systems

Processing types

Transaction processing is distinct from other computer processing models – batch processing, time-sharing, and real-time processing.

Batch processing

Batch processing is execution of a series of programs (jobs) on a computer without manual intervention. Several transactions, called a batch are collected and processed at the same time. The results of each transaction are not immediately available when the transaction is being entered;^[1] there is a time delay.

Real-time processing

"Real time systems attempt to guarantee an appropriate response to a stimulus or request quickly enough to affect the conditions that caused the stimulus." Each transaction in real-time processing is unique; it is not part of a group of transactions.

Time-sharing

Time sharing is the sharing of a computer system among multiple users, usually giving each user the illusion that they have exclusive control of the system. The users may be working on the same project or different projects, but there are usually few restrictions on the type of work each user is doing.

Transaction processing

A Transaction Processing System (TPS) is a type of information system that collects, stores, modifies and retrieves the data transactions of an enterprise. Transaction processing systems also attempt to provide predictable response times to requests, although this is not as critical as for real-time systems. Rather than allowing the user to run arbitrary programs as time-sharing, transaction processing allows only predefined, structured transactions. Each transaction is usually short duration and the processing activity for each transaction is programmed in advance.

Transaction processing system features

The following features are considered important in evaluating transaction processing systems.

Performance

Fast performance with a rapid response time is critical. Transaction processing systems are usually measured by the number of transactions they can process in a given period of time.

Continuous availability

The system must be available during the time period when the users are entering transactions. Many organizations rely heavily on their TPS; a breakdown will disrupt operations or even stop the business.

Data integrity

The system must be able to handle hardware or software problems without corrupting data. Multiple users must be protected from attempting to change the same piece of data at the same time, for example two operators cannot sell the same seat on an airplane.

Ease of use

Often users of transaction processing systems are casual users. The system should be simple for them to understand, protect them from data-entry errors as much as possible, and allow them to easily correct their errors.

Modular growth

The system should be capable of growth at incremental costs, rather than requiring a complete replacement. It should be possible to add, replace, or update hardware and software components without shutting down the system.

Processing in a batch

Transactions may be collected and processed as in batch processing. Transactions will be collected and later updated as a batch when it's convenient or economical to process them. Historically, this was the most common method as the information technology did not exist to allow real-time processing.

Processing in real-time

This is the immediate processing of data. It provides instant confirmation of a transaction. It may involve a large number of users who are simultaneously performing transactions which change data. Because of advances in technology (such as the increase in the speed of data transmission and larger bandwidth), real-time updating is possible.

Databases for transaction processing

A database is an organized collection of data. Databases offer fast retrieval times for non-structured requests as in a typical transaction processing application.

Databases for transaction processing may be constructed using hierarchical, network, or relational structures.

The following features are desirable in a database system used in transaction processing systems:

Backup procedures

Since business organizations have become very dependent on transaction processing, a breakdown may disrupt the business' regular routine and stop its operation for a certain amount of time. In order to prevent data loss and minimize disruptions there have to be well-designed backup and recovery procedures. The recovery process can rebuild the system when it goes down.

Recovery process

A TPS may fail for many reasons such as system failure, human errors, hardware failure, incorrect or invalid data, computer viruses, software application errors or natural or man-made disasters. As it's not possible to prevent all failures, a TPS must be able to detect and correct errors when they occur and cope with failures. A TPS will go through a recovery of the database which may involve the backup, journal, checkpoint, and recovery manager:

Depending on how the system failed, there can be two different recovery procedures used. Generally, the procedures involves restoring data that has been collected from a backup device and then running the transaction processing again. Two types of recovery are backward recovery and forward recovery:

Types of back-up procedures

There are two main types of back-up procedures: grandfather-father-son and partial backups:

Grandfather-father-son

This procedure involves taking complete backups of all data at regular intervals – daily, weekly, monthly, or whatever is appropriate. Multiple generations of backup are retained, often three which gives rise to the name. The most recent backup is the son, the previous the father, and the oldest backup is the grandfather. This method is commonly used for a batch transaction processing system with a magnetic tape. If the system fails during a batch run, the master file is recreated by restoring the son backup and then restarting the batch. However, if the son backup fails, is corrupted or destroyed, then the previous generation of backup (the father) is used. Likewise, if that fails, then the generation of backup previous to the father (i.e. the grandfather) is required. Of course the older the generation, the more the data may be out of date. Organize only of records that have changed. For example, a full backup could be performed weekly, and partial backups taken nightly. Recovery using this scheme involves restoring the last full backup and then restoring all partial backups in order to produce an up-to-date database. This process is quicker than taking only complete backups, at the expense of longer recovery time.

Backup plus journal

This technique is also used in conjunction with regular complete backups. The master file is backed up at regular intervals. Completed transactions since the last backup are stored separately and are called journals, or journal files. The master file can be recreated by restoring the last complete backup and then reprocessing transactions from the journal files. This will produce the most up-to-date copy of the database, but recovery may take longer because of the time required to process a volume of journal records.