Transaction Processing

Transaction processing means dividing information processing up into individual, indivisible operations, called transactions, that complete or fail as a whole; a transaction can’t remain in an intermediate or incomplete state (so other processes can’t access the transaction’s data until either the transaction has completed or it has been “rolled back” after failure). Transaction processing is designed to maintain database integrity (the consistency of related data items) in a known, consistent state.
A transaction, a typical example of which would be a customer order, consists of a series of events (accepting the order, allocating stock and so forth) that are treated as a whole. While theoretically transaction processing is a subset of event processing the integrity considerations described above mean that it is treated as a separate function.
Transaction processing databases are databases that have been designed specifically to optimise the performance of transaction processing, which is often referred to as OLTP (online transaction processing).

What does it do…?

Relational database management systems (DBMSs) were originally designed to support transaction processing. An example of a transaction would be processing a customer order and all the ancillary requirements that go along with that, such as decrementing inventory, arranging shipping, placing manufacturing orders and so on. Transactions may also occur in other environments, for example between an organisation and its staff (HR applications), in marketing, production control and elsewhere. Typically, but not always, these types of applications have been implemented on top of relational databases.
However, relational DBMSs are not the only vehicles for transaction processing for historical reasons as well as (sometimes) for valid technical reasons.In addition to transactional applications based on purely relational data, relational databases have subsumed XML and object-oriented capabilities over the years so that hybrid transactional environments that require the use of these technologies alongside relational data also fall into this category though pure-play XML and object-oriented databases remain part of the market for specialist applications.
In addition, there are still many companies that rely on older, hierarchical DBMSs for OLTP (on-line transaction processing) partly because of the difficulties involved with migrating away from those platforms and also partly because these types of databases are very efficient for this type of workload. There are also large numbers of companies that rely on multi-valued (sometimes called NF2) databases for applications that have typically been provided as a package by a third party.
Apart from performance and other generalised considerations the major requirements for transaction processing databases are so-called ACID properties and, typically, support for XA-compliant two-phase commit (where an XA compliant driver is a driver that can participate in anXA compliant transaction as defined by the X/Open specification). The former are properties that ensure that transactions are processed reliably and the latter specifically supports atomicity (the A in ACID), ensuring that all transactions are either completed in full or rolled back. Note that there are a variety of XML, NoSQL and Graph databases that are both ACID and XA compliant.