Loading article…
コンピュータサイエンスにおいて、トランザクション処理とは、トランザクションと呼ばれる個々の不可分な操作に分割された情報処理[ 1 ]のことである。各トランザクションは完全な単位として成功するか失敗するかのどちらかであり、部分的にしか完了しないことはない。
例えば、オンライン書店で本を購入する場合、あなたは（クレジットという形で）お金と本を交換します。クレジットが正常であれば、一連の関連操作によって、あなたは本を受け取り、書店はあなたのお金を受け取ることができます。しかし、交換中に一連の操作のいずれかが失敗すると、交換全体が失敗します。あなたは本を受け取ることができず、書店はあなたのお金を受け取ることができません。この交換のバランスと予測可能性を確保する技術は、トランザクション処理と呼ばれます。トランザクションは、トランザクション単位内のすべての操作が正常に完了しない限り、データ指向のリソースが永続的に更新されないことを保証します。一連の関連操作を、完全に成功するか完全に失敗するかのどちらかである単位にまとめることで、エラー回復を簡素化し、アプリケーションの信頼性を高めることができます。
トランザクション処理システムは、ビジネスを行う上で必要な定型的なトランザクションを実行するトランザクション指向アプリケーションをホストするコンピュータハードウェアとソフトウェアで構成されます。例としては、販売注文入力、航空券予約、給与計算、従業員記録、製造、出荷などを管理するシステムがあります。
今日では、すべての取引処理ではないものの、ほとんどの取引処理は対話型であるため、この用語はオンライン取引処理と同義語として扱われることが多い。
トランザクション処理は、システム上の相互依存的な操作がすべて正常に完了するか、すべて正常にキャンセルされることを保証することにより、システムの整合性（通常はデータベースまたは一部の最新のファイルシステム）を既知の一貫した状態に維持するように設計されています。
例えば、顧客の普通預金口座から当座預金口座へ700ドルを移動させるという、典型的な銀行取引を考えてみましょう。この取引は、コンピュータ上では少なくとも2つの別々の操作、つまり普通預金口座から700ドルを引き落とす操作と、当座預金口座から700ドルを入金する操作から構成されます。もし一方の操作が成功しても他方が失敗した場合、銀行の帳簿は一日の終わりにバランスが取れなくなります。したがって、銀行のデータベース全体に矛盾が生じないよう、両方の操作が必ず成功するか、両方とも失敗するかのどちらかになるようにする必要があります。
トランザクション処理は、複数の個別の操作を単一の不可分なトランザクションにリンクし、トランザクション内のすべての操作がエラーなく完了するか、あるいはどれもエラーなく完了するかのいずれかであることを保証します。一部の操作は完了したものの、他の操作の実行中にエラーが発生した場合、トランザクション処理システムはトランザクション内のすべての操作（成功した操作も含む）を「ロールバック」し、トランザクションの痕跡をすべて消去して、トランザクション処理開始前の一貫性のある既知の状態にシステムを復元します。トランザクション内のすべての操作が正常に完了した場合、システムはトランザクションをコミットし、データベースへのすべての変更を永続化します。この処理が完了すると、トランザクションをロールバックすることはできません。
トランザクション処理は、トランザクションが部分的にしか完了しない原因となるハードウェアおよびソフトウェアのエラーからシステムを保護します。トランザクション処理中にコンピュータシステムがクラッシュした場合、トランザクション処理システムは、コミットされていないトランザクション内のすべての操作がキャンセルされることを保証します。
一般的に、トランザクションは同時に発行されます。トランザクションが重複する場合（つまり、データベースの同じ部分にアクセスする必要がある場合）、競合が発生する可能性があります。たとえば、上記の例で述べた顧客が貯蓄口座に150ドルを持っていて、100ドルを別の人に送金しようとし、同時に100ドルを当座預金口座に移動しようとした場合、どちらか一方しか成功しません。しかし、トランザクションを強制的に順次処理するのは非効率的です。そのため、トランザクション処理の並行実装では、トランザクションを任意の順序で順次実行した場合と同じ結果（直列化可能性と呼ばれる特性）が競合のない結果となるようにプログラムされています。この例では、どちらのトランザクションが最初に発行されたかに関わらず、別の人への送金か当座預金口座への移動のどちらかが成功し、もう一方は失敗することを意味します。
トランザクション処理システムの基本原理はすべて同じです。ただし、用語はトランザクション処理システムによって異なる場合があり、以下で使用する用語は必ずしも普遍的なものではありません。
トランザクション処理システムは、データベースが変更される際の中間状態を記録し、トランザクションがコミットできない場合にこれらの記録を使用してデータベースを既知の状態に復元することで、データベースの整合性を確保します。たとえば、トランザクションによる変更前のデータベース情報のコピーは、トランザクションが変更を行う前にシステムによって保存されます（これは「ビフォアイメージ」と呼ばれることもあります）。トランザクションの一部がコミット前に失敗した場合、これらのコピーを使用してデータベースをトランザクション開始前の状態に復元します。
データベース管理システムへのすべての変更を別のジャーナルに記録することも可能です（アフターイメージと呼ばれることもあります）。これは失敗したトランザクションのロールバックには必須ではありませんが、データベース障害発生時にデータベース管理システムを更新するのに役立つため、一部のトランザクション処理システムではこの機能を提供しています。データベース管理システムが完全に障害を起こした場合は、最新のバックアップから復元する必要があります。バックアップには、バックアップ作成以降にコミットされたトランザクションは反映されません。しかし、データベース管理システムが復元されると、アフターイメージのジャーナルをデータベースに適用（ロールフォワード）して、データベース管理システムを最新の状態にすることができます。障害発生時に進行中だったトランザクションは、その後ロールバックできます。結果として、障害発生時までにコミットされたすべてのトランザクションの結果を含む、一貫性のある既知の状態のデータベースが得られます。
場合によっては、2つのトランザクションが処理中にデータベースの同じ部分へ同時にアクセスしようとして、処理が進まなくなることがあります。たとえば、トランザクションAがデータベースのX部分にアクセスし、トランザクションBがY部分にアクセスするとします。その時点で、トランザクションAがY部分にアクセスしようとし、同時にトランザクションBがX部分にアクセスしようとすると、デッドロックが発生し、どちらのトランザクションも先に進めなくなります。トランザクション処理システムは、このようなデッドロックが発生したときに検出するように設計されています。通常、両方のトランザクションはキャンセルされ、ロールバックされた後、自動的に異なる順序で再開され、デッドロックが再び発生しないようにします。あるいは、デッドロックが発生したトランザクションのうち、1つだけがキャンセルされ、ロールバックされた後、短い遅延の後に自動的に再開される場合もあります。
デッドロックは、3つ以上のトランザクション間でも発生する可能性があります。関与するトランザクションの数が増えるほど、デッドロックの検出は困難になり、トランザクション処理システムでは検出できるデッドロックの数に実際的な限界があることがわかっています。
コミットおよびロールバック機構が利用できない、あるいは望ましくないシステムでは、失敗したトランザクションを取り消し、システムを以前の状態に復元するために、補償トランザクションがよく使用されます。
ジム・グレイは1970年代後半に、信頼性の高いトランザクションシステムの特性をACID（原子性、一貫性、分離性、耐久性）という頭字語で定義した。[ 1 ]
トランザクションによる状態変更はアトミックです。つまり、すべて実行されるか、何も実行されないかのどちらかです。これらの変更には、データベースの変更、メッセージ、およびトランスデューサに対するアクションが含まれます。
一貫性：トランザクションは、状態の正しい変換である。グループとして実行されるアクションは、状態に関連付けられた整合性制約のいずれにも違反しない。
トランザクションは同時に実行されるが、各トランザクションTからは、他のトランザクションがTより前に実行されたか、Tより後に実行されたかのどちらかであり、両方同時に実行されたことはないように見える。
トランザクションが正常に完了（コミット）すると、データベースへの変更は障害発生後も保持され、変更内容は維持されます。
IBMの情報管理システムなどの標準的なトランザクション処理ソフトウェアは、1960 年代に初めて開発され、多くの場合、特定のデータベース管理システムと密接に連携していました。クライアント/サーバー コンピューティングは、1980 年代に同様の原理を実装しましたが、成功と失敗はまちまちでした。しかし、近年では、分散クライアント/サーバー モデルの維持管理が著しく困難になっています。さまざまなオンライン サービス (特に Web )に対応してトランザクション数が増加するにつれて、単一の分散データベースは実用的な解決策ではなくなりました。さらに、ほとんどのオンライン システムは、単一のサーバーがトランザクション処理を処理できる厳密なクライアント/サーバー モデルとは異なり、連携して動作する一連のプログラムで構成されています。今日では、プログラム間レベルで動作し、メインフレームを含む大規模システムにも拡張可能なトランザクション処理システムが数多く存在します。
一つの取り組みとして、X/Open Distributed Transaction Processing (DTP) があります（Java Transaction API (JTA) も参照）。しかし、IBMのCICSのような独自のトランザクション処理環境は依然として非常に人気があり、CICSはオープンな業界標準も取り入れるように進化しています。
エクストリームトランザクション処理（XTP）という用語は、特にスループット要件（1秒あたりのトランザクション数）など、非常に厳しい要件を持つトランザクション処理システムを説明するために使用されました。このようなシステムは、分散型またはクラスタ型のアーキテクチャを介して実装される場合があります。少なくとも2011年までには使用されていました。[ 2 ] [ 3 ]