とは、トランザクションと呼ばれる不可分な操作から構成される情報処理の形態。

解説
トランザクションは、データベースをある一貫した状態から別の一貫した状態へ変更するアクションを1つに束ねたものである。トランザクション処理は、既知の一貫した状態のデータベースを維持するよう設計されており、相互依存のある複数の操作が全て完了するか、全てキャンセルされることを保証する。

例えば、顧客の普通預金口座から当座預金口座に500ドルを移動させる典型的な銀行のトランザクションを考えて見る。このトランザクションは銀行側から見れば1つの操作であるが、コンピュータから見れば少なくとも2つの操作から構成される。普通預金口座から500ドルを引き落とし、当座預金口座に500ドルを入金するのである。引き落としが成功して入金が失敗した場合（あるいは逆の場合）、銀行の帳簿はその日の営業完了時点で不整合を生じる。したがって、2つの操作が両方成功するか、両方失敗することを保証する必要があり、それによって銀行のデータベースに不整合が生じないようにする。トランザクション処理はそのような保証をするよう設計されている。

トランザクション処理では、データベースの個々の操作が自動的に1つに連結され、不可分のトランザクションとされることがある。トランザクション処理システムは、1つのトランザクション内の全操作がエラー無しに成功するか、全操作が実行されないことを保証する。一部の操作が成功し、他の操作でエラーが発生した場合、トランザクション処理システムはそのトランザクションの「全」操作を「ロールバック; roll back」し、そのトランザクションによる痕跡を消去してデータベースを一貫した状態（そのトランザクションを開始する前の状態）にリストアする。あるトランザクションの全操作が完了した場合、そのトランザクションはシステムによって「コミット; commit」され、データベースに加えられた更新内容が恒久的なものとなる。コミットされたトランザクションがロールバックされることはない。

トランザクション処理は、ハードウェアやソフトウェアの障害によってトランザクションが部分的に実行され、データベースが不明で一貫しない状態になるのも防ぐ。コンピュータシステムがトランザクションを処理中にクラッシュしてしまった場合、トランザクション処理システムはコミットされていない全トランザクションがキャンセルされることを保証する。

トランザクションは厳密に時間順に処理される。n+1 番目のトランザクションが n 番目のトランザクションと同じデータベース内のデータにアクセスする場合、n 番目のトランザクションがコミットされるまで n+1 番目のトランザクションは開始されない。あるトランザクションが開始される前にそのトランザクションが操作する予定のデータベースの部分を更新している全トランザクションは先にコミットされなければならない。先行するトランザクション群には hole は全く存在しない。

技法
トランザクション処理システムの基本原則は、どのようなシステムであっても同じである。しかし、システムによって用語が異なる可能性があり、以下で使用する用語は必ずしも常に通用するとは限らない。

ロールバック

トランザクション処理システムはデータベースの整合性を保証するため、データベース更新の中間状態を記録し、トランザクションがコミットできなかった場合にデータベースを既知の状態にリストアするためにそのような記録を活用する。例えば、トランザクションによる更新前のデータベースの情報のコピーを事前に取って置く（これをbefore imageと呼ぶ）。トランザクションがコミット前に失敗した場合、そのコピーを使ってデータベースをトランザクション開始前の状態に戻す。これを「ロールバック」と呼ぶ。

ロールフォワード
また、データベースへの更新毎に別にジャーナルを保持することも可能である（これをafter imageと呼ぶ）。これはトランザクション失敗時のロールバックには不要だが、データベースの障害発生時のアップデートには便利である。そのためトランザクション処理システムでもこれを提供している場合がある。データベース全体の障害が発生した場合、最近とられたバックアップからデータベースを復元する。バックアップは、バックアップ採取後にコミットされたトランザクションによる更新を反映していない。しかし、データベースをリストアした後、after imageのジャーナルをデータベースに適用してデータベースを最新状態にすることができる。これを「ロールフォワード」と呼ぶ。障害発生時に処理中だったトランザクションはロールバックされる。これにより、障害発生直前までにコミットされた全トランザクションが反映された一貫した状態のデータベースが復旧できる。

デッドロック

場合によっては、2つのトランザクションの処理中にデータベース内の同じ部分に同時にアクセスしようとして、互いの処理の進行を妨げる場合がある。例えば、トランザクション A が X にアクセスし、トランザクション B が Y にアクセスしているとしよう。その状態で、A が Y にアクセスしようとし、B が X にアクセスしようとしたとき「デッドロック」が発生し、どちらのトランザクションも先に進めなくなる。トランザクション処理システムはそのようなデッドロックが発生するのを検出するよう設計されている。通常、両方のトランザクションをキャンセルし、ロールバックする。そして、自動的に順序を変えて再実行し、デッドロックが再度発生しないようにする。

ACID 標準

トランザクション処理システムがデータベースの一貫性を保つ手法には様々な微妙な差異があるが、基本原則に違いはない。あらゆるトランザクション処理システムはACID属性（アトミック性、一貫性、独立性、永続性）と呼ばれる機能をサポートしている。

実装
IBMのIMSなどの標準的なトランザクション処理ソフトウェアは1960年代に開発が始まった。それらは特定のデータベース管理システム (DBMS) と密に結合されていることが多い。1980年代には同様の基本機能を実装したクライアントサーバシステムが成功を収めた。しかし近年、分散クライアントサーバシステムの保守が益々困難となってきた。（特に ウェブによる）オンラインサービスの増加に伴ってトランザクション数が増加し、単一のデータベースは現実的な選択ではなくなってきた。さらにクライアントサーバモデルでは単一のサーバがトランザクション処理を行うのに対して、多くのオンラインシステムは各種プログラムが協調動作することで構成されるようになってきた。今日ではプログラムレベルのトランザクション処理システムが数多く稼動しており、それをメインフレームを含む巨大なシステムにまで適用可能である。

業界標準としては、X/Open Distributed Transaction Processing (DTP) が重要である。しかし、IBM の CICS のようなプロプライエタリなトランザクションシステムも依然として多数利用されている。もっとも、CICS はオープンな業界標準も取り入れてきた。

脚注

参考文献  

Jim Gray, Andreas Reuter, Transaction Processing - Concepts and Techniques, 1993, Morgan Kaufmann, ISBN 1558601902
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 1558602143

関連項目  
トランザクション
ACID
ツーフェーズコミット
オンライントランザクション処理
トランザクションモニター
CICS
IMS
Jakarta EE （例えば、WebSphere Application Server）
Java Transaction API (JTA)
Transaction Processing Facility (z/TPF)

nl:Transactie (dataopslag)#Uitleg