In computer science, transaction processing is information processing that is divided into individual, indivisible operations, called transactions. Each transaction must succeed or fail as a complete unit; it cannot remain in an intermediate state. Transaction mandatorily requires acknowledgment to get received as a necessary feedback for accomplishment.
Transaction processing is designed to maintain a computer system (typically a database or some modern filesystems) in a known, consistent state, by ensuring that any operations carried out on the system that are interdependent are either all completed successfully or all canceled successfully.
For example, consider a typical banking transaction that involves moving $700 from a customer's savings account to a customer's checking account. This transaction is a single operation in the eyes of the bank, but it involves at least two separate operations in computer terms: debiting the savings account by $700, and crediting the checking account by $700. If the debit operation succeeds but the credit does not (or vice versa), the books of the bank will not balance at the end of the day. There must therefore be a way to ensure that either both operations succeed or both fail, so that there is never any inconsistency in the bank's database as a whole. Transaction processing is designed to provide this.
Transaction processing allows multiple individual operations to be linked together automatically as a single, indivisible transaction. The transaction-processing system ensures that either all operations in a transaction are completed without error, or none of them are. If some of the operations are completed but errors occur when the others are attempted, the transaction-processing system “rolls back” all of the operations of the transaction (including the successful ones), thereby erasing all traces of the transaction and restoring the system to the consistent, known state that it was in before processing of the transaction began. If all operations of a transaction are completed successfully, the transaction is committed by the system, and all changes to the database are made permanent; the transaction cannot be rolled back once this is done.
Transaction processing guards against hardware and software errors that might leave a transaction partially completed, with the system left in an unknown, inconsistent state. If the computer system crashes in the middle of a transaction, the transaction processing system guarantees that all operations in any uncommitted (i.e., not completely processed) transactions are cancelled.
Transactions are processed in a strict chronological order. If transaction n+1 intends to touch the same portion of the database as transaction n, transaction n+1 does not begin until transaction n is committed. Before any transaction is committed, all other transactions affecting the same part of the system must also be committed; there can be no “holes” in the sequence of preceding transactions.
The basic principles of all transaction-processing systems are the same. However, the terminology may vary from one transaction-processing system to another, and the terms used below are not necessarily universal.
Transaction-processing systems ensure database integrity by recording intermediate states of the database as it is modified, then using these records to restore the database to a known state if a transaction cannot be committed. For example, copies of information on the database prior to its modification by a transaction are set aside by the system before the transaction can make any modifications (this is sometimes called a before image). If any part of the transaction fails before it is committed, these copies are used to restore the database to the state it was in before the transaction began.
It is also possible to keep a separate journal of all modifications to a database (sometimes called after images); this is not required for rollback of failed transactions, but it is useful for updating the database in the event of a database failure, so some transaction-processing systems provide it. If the database fails entirely, it must be restored from the most recent back-up. The back-up will not reflect transactions committed since the back-up was made. However, once the database is restored, the journal of after images can be applied to the database (rollforward) to bring the database up to date. Any transactions in progress at the time of the failure can then be rolled back. The result is a database in a consistent, known state that includes the results of all transactions committed up to the moment of failure.
In some cases, two transactions may, in the course of their processing, attempt to access the same portion of a database at the same time, in a way that prevents them from proceeding. For example, transaction A may access portion X of the database, and transaction B may access portion Y of the database. If, at that point, transaction A then tries to access portion Y of the database while transaction B tries to access portion X, a deadlock occurs, and neither transaction can move forward. Transaction-processing systems are designed to detect these deadlocks when they occur. Typically both transactions will be cancelled and rolled back, and then they will be started again in a different order, automatically, so that the deadlock doesn't occur again. Or sometimes, just one of the deadlocked transactions will be cancelled, rolled back, and automatically re-started after a short delay.
Deadlocks can also occur between three or more transactions. The more transactions involved, the more difficult they are to detect, to the point that transaction processing systems find there is a practical limit to the deadlocks they can detect.
In systems where commit and rollback mechanisms are not available or undesirable, a Compensating transaction is often used to undo failed transactions and restore the system to a previous state.
ACID criteria (Atomicity, Consistency, Isolation, Durability)
Transaction processing has these benefits:
- It allows sharing of computer resources among many users
- It shifts the time of job processing to when the computing resources are less busy
- It avoids idling the computing resources without minute-by-minute human interaction and supervision
- It is used on expensive classes of computers to help amortize the cost by keeping high rates of utilization of those expensive resources
- A transaction is an atomic unit of processing.
Standard transaction-processing software, notably IBM's Information Management System, was first developed in the 1960s, and was often closely coupled to particular database management systems. client–server computing implemented similar principles in the 1980s with mixed success. However, in more recent years, the distributed client–server model has become considerably more difficult to maintain. As the number of transactions grew in response to various online services (especially the Web), a single distributed database was not a practical solution. In addition, most online systems consist of a whole suite of programs operating together, as opposed to a strict client–server model where the single server could handle the transaction processing. Today a number of transaction processing systems are available that work at the inter-program level and which scale to large systems, including mainframes.
An important open industry standard is the X/Open Distributed Transaction Processing (DTP) (see JTA). However, proprietary transaction-processing environments such as IBM's CICS are still very popular, although CICS has evolved to include open industry standards as well.
A modern transaction processing implementation combines elements of both object-oriented persistence with traditional transaction monitoring. One such implementation is the commercial DTS/S1 product from Obsidian Dynamics, or the open-source product db4o.
- Audit trail
- Compensating transaction
- Concurrent programming
- Database transaction
- Extreme Transaction Processing (XTP)
- IBM TXSeries (CICS on distributed platforms)
- Java EE (e.g. WebSphere Application Server)
- Java Transaction API (JTA)
- Two-phase commit
- Transaction Processing Facility
- Tuxedo (software)
- Transaction Processing Management System (TPMS)
- Transaction Processing Performance Council (TPC)
- Telecommunication Application Transaction Processing Benchmark (TATP)
- Gerhard Weikum, Gottfried Vossen, Transactional information systems: theory, algorithms, and the practice of concurrency control and recovery, Morgan Kaufmann, 2002, ISBN 1558605088
- Jim Gray, Andreas Reuter, Transaction Processing — Concepts and Techniques, 1993, Morgan Kaufmann, ISBN 1-55860-190-2
- Philip A. Bernstein, Eric Newcomer, Principles of Transaction Processing, 1997, Morgan Kaufmann, ISBN 1-55860-415-4
- Ahmed K. Elmagarmid (Editor), Transaction Models for Advanced Database Applications, Morgan-Kaufmann, 1992, ISBN 1-55860-214-3
Database management systems Concepts Objects Components
Wikimedia Foundation. 2010.
Look at other dictionaries:
transaction processing — ➔ processing * * * transaction processing UK US noun [U] ► IT the use of a computer system to organize transactions (= actions that change information) in a database ► COMMERCE the system used by a company to deal with its sales: »The Service… … Financial and business terms
transaction processing — noun (computing) The use of an online computer to interrogate or update files in real time • • • Main Entry: ↑transact … Useful english dictionary
transaction processing — A processing method in which transactions are executed immediately when they are received by the system, rather than at some later time as in batch processing systems. Airline reservation databases and automatic teller machines are examples of … Dictionary of networking
Transaction Processing over XML — (TPoX) is a computing benchmark for XML database systems. As a benchmark, TPoX is used for the performance testing of database management systems that are capable of storing, searching and retrieving XML data. The goal of TPoX is to allow… … Wikipedia
Transaction Processing Performance Council — (TPC) is a non profit organization founded in 1988 to define transaction processing and database benchmarks and to disseminate objective, verifiable TPC performance data to the industry. TPC benchmarks are widely used today in evaluating the… … Wikipedia
Transaction Processing Facility — (TPF) ist ein Echtzeitbetriebssystem für die IBM Großrechner der System/360 und der System z Familien. TPF wurde aus dem Airline Control Program (ACP) von IBM und mehreren nordamerikanischen und europäischen Fluggesellschaften entwickelt. 1979… … Deutsch Wikipedia
Transaction Processing over XML — (TPoX) ist die Bezeichnung eines von der IBM entwickelten Benchmarks zur Performancemessung von XML Datenbanken. Die Version 1.0 der Spezifikation wurde im Dezember 2006 vorgestellt, Version 2.0 folgte im Juni 2009. Weblinks TPoX bei… … Deutsch Wikipedia
Transaction processing system — A Transaction Processing System To be considered a transaction processing system the computer must pass the ACID test.From a technical perspective, a Transaction Processing System (or Transaction Processing Monitor) monitors transaction programs … Wikipedia
Transaction Processing Facility — Infobox OS name = z/TPF caption = developer = IBM source model = Closed source (Source code is available to licenced users with restrictions) kernel type = Real time supported platforms = ? ui = ? family = z/TPF released = latest release version … Wikipedia
Transaction Processing Performance Council — Le Transaction Processing Performance Council (TPC) est un organisme a but non lucratif dont l activité consiste à élaborer des tests de performance de systèmes informatiques transactionnels. Les éditeurs publient régulièrement les records… … Wikipédia en Français