1.7. トランザクションサービスの特性
トランザクションシステムを実装する製品を選択する場合に、さまざまなデータベース製品やトランザクションマネージャーが無料または商用で利用できます。これらはすべて、トランザクション処理のサポートが通常通りありますが、これらの製品がサポートするサービスの特性は各種あります。このセクションでは、さまざまなトランザクション製品の信頼性と洗練度を比較するときに考慮する必要のある機能の種類について簡単に説明します。
1.7.1. リソースが提供するサービスの特性
以下の機能は、リソースの QoS(Quality of Service) を決定します。
1.7.1.1. トランザクション分離レベル
ANSI SQL は、以下のように 4 つの トランザクション分離レベル を定義します。
SERIALIZABLE- トランザクションは相互に完全に分離されます。つまり、1 つのトランザクションはトランザクションがコミットされるまで他のトランザクションに影響を与えることはありません。この分離レベルは、すべてのトランザクションが次々に実行されたかのように影響を与えるので、serializable として記述されます。(ただし、実際には、リソースはアルゴリズムを最適化できることが多く、一部のトランザクションを同時に続行できます)。
REPEATABLE_READ-
トランザクションがデータベースを読み取りまたは更新するたびに、読み取りまたは書き込みロックが取得され、トランザクションが終了するまで保持されます。これにより、ほぼ完全な分離が可能になります。ただし、分離が十分ではないというケースが 1 つあります。
WHERE句を使用して行の範囲を読み取る SQL のSELECTステートメントについて考えてみましょう。最初のトランザクションの実行中に別のトランザクションがこの範囲に行を追加する場合、最初のトランザクションはSELECTの呼び出しを繰り返すと (ファントム読み取り)、この新しい行を確認できます。 READ_COMMITTED- 書き込みロックは、トランザクションが終了するまで保持されます。読み取りロックは、トランザクションが終了するまで保持されません。その結果、他のトランザクションによってコミットされた更新が進行中のトランザクションに表示されるようになるため、読み取りを繰り返すと異なる結果が得られる可能性があります。
READ_UNCOMMITTED- トランザクションが終了するまで、読み取りロックも書き込みロックも保持されません。そのため、ダーティリードが可能です。ダーティレディとは、他のトランザクションによって行われた変更の内、コミットされていない変更が進行中のトランザクションに表示される場合です。
データベースは通常、さまざまなトランザクション分離レベルのすべてをサポートしているわけではありません。たとえば、一部の無料データベースは READ_UNCOMMITTED のみをサポートします。また、一部のデータベースは、ANSI 規格とは微妙に異なる方法でトランザクション分離レベルを実装しています。分離は、データベースのパフォーマンスが犠牲にある複雑な問題です (たとえば、Wikipedia の分離 を参照してください)。
1.7.1.2. XA 標準のサポート
複数のリソースを含むトランザクションに参加するには、X/Open XA 標準をサポートする必要があります。XA 標準のリソースの実装が特別な制限を受けているかどうかを必ず確認してください。たとえば、XA 標準の一部の実装は、単一のデータベース接続に制限されており、一度に 1 つのスレッドのみがそのリソースを含むトランザクションを処理できることを意味します。
1.7.2. トランザクションマネージャーが提供するサービスの特性
以下の機能は、トランザクションマネージャーの QoS (Quality of Service) を決定します。
1.7.2.1. 一時停止/再開およびアタッチ/デタッチのサポート
トランザクションマネージャーの中には、以下のようにトランザクションコンテキストとアプリケーションスレッド間の関連付けを操作する高度な機能がサポートされます。
- 現在のトランザクションの一時停止/再開: アプリケーションが現在のスレッドでトランザクション意外の作業を実行している間、現在のトランザクションコンテキストを一時的に停止できます。
- トランザクションコンテキストのアタッチ/デタッチ: トランザクションコンテキストをあるスレッドから別のスレッドに移動したり、トランザクションスコープを拡張して複数のスレッドを含めることができます。
1.7.2.2. 複数リソースのサポート
トランザクションマネージャーの主な違いは、複数のリソースをサポートする機能です。これには通常、XA 標準のサポートが必要であり、トランザクションマネージャーはリソースが XA スイッチを登録する方法を提供します。
厳密に言えば、XA 標準は、複数リソースのサポートに使用できる唯一のアプローチではありませんが、最も実用的なアプローチです。代わり方法として、通常 XA スイッチによって提供されるアルゴリズムを実装するために、面倒な (および重要な) カスタムコードを記述する必要があります。
1.7.2.3. 分散トランザクション
一部のトランザクションマネージャーには、分散システム内の複数のノードがスコープに含まれるトランザクションを管理する機能があります。トランザクションコンテキストは、WS-AtomicTransactions または CORBA OTS などの特別なプロトコルを使用してノードからノードに伝播されます。
1.7.2.4. トランザクションの監視
通常、高度なトランザクションマネージャーは、保留中のトランザクションの状態を監視する視覚的なツールを提供します。この種のツールは、システム障害後に特に便利です。システム障害は、不確実な状態 (ヒューリスティックな例外) のままになっているトランザクションを特定して解決するのに役立ちます。
1.7.2.5. 障害からの復旧
トランザクションマネージャーはそれぞれ、システム障害 (クラッシュ) が発生した場合の堅牢性に大きな違いがあります。トランザクションマネージャーが使用する主なストラテジーは、トランザクションの各ステップを実行する前にデータを永続ログに書き込むことです。失敗した場合、ログのデータを使用してトランザクションを復元できます。一部のトランザクションマネージャーは、他のマネージャーよりも慎重にこのストラテジーを実装します。たとえば、ハイエンドトランザクションマネージャーは通常、永続的なトランザクションログを複製し、各ログを別のホストマシンに保存できるようにします。
