制約事項: 本トピックは、Windows 環境にのみ該当します。
メインフレームの DB2 アプリケーションでは任意の形式のストアド プロシージャのフローを呼び出すと、連鎖されている一連の連続トランザクションが実行されます。例えば、COBOL クライアント アプリケーションから実行される次のシーケンスについて考えてみましょう。
Insert 1
Call COBOL stored procedure A
Insert 2
Call COBOL routine B
Commit
Insert 3
Rollback
Insert 4
Insert 5
Commit
DB2 ではレコード 1、2、4 および 5 を挿入します。
ただし、SQL Server では、アプリケーションで任意の種類のストアド プロシージャのフローが呼び出されると、そのストアド プロシージャはネストされたトランザクションを形成します。トランザクションが実行した処理の内容にかかわらず、このネストされたトランザクションの最も外側のトランザクションが、含まれているすべてのトランザクションの作業をコミットするか、ロールバックするかを最終的に決定します。この例では、COBOL クライアント アプリケーションがネストされたトランザクションを開始し、COMMIT で終了しているため、5 つのレコードすべてが挿入されます。アプリケーションが COMMIT ではなく ROLLBACK で終了する場合は、5 つのレコードはいずれも挿入されません。
この動作は、移行した SQL Server アプリケーションに DB2 トランザクションの連鎖を模倣させる必要がある場合は、許容されません。
SQL Server では、implicit_transactions とセーブポイントの組み合わせを使用することができます。implicit_transactions が OFF または ON に設定されている場合、SQL Server にワークロードをコミットし、ロックを解除する先頭トランザクションを配置します。セーブポイントは、連続的に連鎖されている COMMIT および ROLLBACK トランザクションが意図したとおりに動作することを保証します。
注: セーブポイントおよび implicit_transactions の設定の詳細については、
OPTION、
SET AUTOCOMMIT、および
AUTOCOMMIT を参照してください。
HCOSS では、COBOL ストアド プロシージャでのメインフレーム DB2 トランザクションの動作を模倣するソリューションが 3 つ提供されています。implicit_transactions で開始する最初の 2 つは OFF に設定されており、implicit_transactions で開始する 3 つ目は ON に設定されています。次に、各ソリューションの説明とそれぞれの長所と欠点の概要を示します。
- ソリューション 1 および 2:呼び出し元 - Implicit Transactions が OFF (auto-commit モード)
- SQL(AUTOCOMMIT) またはストアド プロシージャを作成するか、ストアド プロシージャの呼び出し前に EXEC SQL SET AUTOCOMMIT ON END-EXEC 文を実行することにより、implicit_transactions を OFF に設定することができます。これは自動コミット モードです。ストアド プロシージャの呼び出し後に EXEC SQL SET AUTOCOMMIT ON END-EXEC 文を実行することにより、自動コミット モードをオフにすることができます。
HCOSS では、次の処理を行います。
|
ON ENTRY |
EXEC SQL COMMIT |
EXEC SQL ROLLBACK |
ON EXIT (返却) |
先頭 (呼び出し先の) ストアド プロシージャ |
トランザクションの開始
セーブポイントの設定
|
コミット
セーブポイントのリセット
|
セーブポイントまでのロールバック
コミット
セーブポイントのリセット
|
オプション 1:
オプション 2:SQL(OPTION=SPCOMMITONRETURN) を使用する
|
ネストされたストアド プロシージャ |
|
セーブポイントのリセット
|
セーブポイントまでのロールバック
|
|
呼び出し先の COBOL ルーチン |
|
コミット
セーブポイントのリセット
|
セーブポイントまでのロールバック
コミット
セーブポイントのリセット
|
|
- ソリューション 1:ネストされたストアド プロシージャの維持
-
メリット |
デメリット |
- コードの変更が最小限:
- ストアド プロシージャ コードへの変更がない (SQLCLRTRANS コンパイル オプション)
- アプリケーション コードは、ストアド プロシージャの呼び出し前に、implicit_transactions を OFF に設定し、ストアド プロシージャの呼び出し後に ON に戻す必要がある場合がある
- ロックは、ワークロードをコミットまたはロールバックするときに先頭のストアド プロシージャによって解放される (並行性はソリューション 3 より高い)
|
- クライアントの作業は、ストアド プロシージャによってコミットまたはロールバックすることはできない (整合性はソリューション 2 と同じだが、ソリューション 3 より低い)
- ストアド プロシージャの作業は、クライアントによってコミットまたはロールバックすることはできない (整合性はソリューション 2 と同じだが、ソリューション 3 より低い)
- ロックは、ネストされたストアド プロシージャによって保持される (並行性はソリューション 2 より低い)
|
- ソリューション 2:ネストされたストアド プロシージャを呼び出し先の COBOL ルーチンと置き換える
-
メリット |
デメリット |
ロックは、コミットまたはロールバックするときに先頭のストアド プロシージャおよび呼び出し先の COBOL ルーチンによって解放される (並行性はソリューション 1 およびソリューション 3 より高い) |
- コードの修正:
- COBOL 呼び出しへのネストされているストアド プロシージャ呼び出しの変更 (SQLCLRTRANS コンパイル オプション)
- アプリケーション コードは、ストアド プロシージャの呼び出し前に、implicit_transactions を OFF に設定し、ストアド プロシージャの呼び出し後に ON に戻す必要がある場合がある
- クライアントの作業は、ストアド プロシージャによってコミットまたはロールバックすることはできない (整合性はソリューション 2 と同じだが、ソリューション 3 より低い)
- ストアド プロシージャの作業は、クライアントによってコミットまたはロールバックすることはできない (整合性はソリューション 2 と同じだが、ソリューション 3 より低い)
|
- ソリューション 3:呼び出し元 - Implicit Transactions が ON
- Implicit_transaction は、ストアド プロシージャの呼び出しの前に ON に設定されます。自動コミット モードがオフになります。このソリューションでは、ネストされたストアド プロシージャはそのまま維持されます。
HCOSS では、次の処理を行います。
|
ON ENTRY |
EXEC SQL COMMIT |
EXEC SQL ROLLBACK |
ON EXIT (返却) |
先頭 (呼び出し先の) ストアド プロシージャ |
|
セーブポイントのリセット
|
セーブポイントまでのロールバック
|
|
ネストされたストアド プロシージャ |
|
セーブポイントのリセット
|
セーブポイントまでのロールバック
|
|
メリット |
デメリット |
- COBOL 以外のアプリケーションのコードの変更が最小限:
- ストアド プロシージャ コードに変更がない (SQL(OPTION=SQLCLRTRANS) でコンパイルする)
- アプリケーション コードは、ストアド プロシージャ呼び出しの前にセーブポイントを設定する必要がある
- アプリケーション コードは、ストアド プロシージャ呼び出しの後にコミットまたはロールバックを発行する必要がある
- 追加のストアド プロシージャ呼び出しが行われた場合は、アプリケーション コードでセーブポイントを設定する必要がある
- COBOL アプリケーションのコードの変更が最小限:
- SQL(OPTION=SQLCLRTRANS) でコンパイルする
- アプリケーション コードは、ストアド プロシージャ呼び出しの後にコミットまたはロールバックを発行する必要がある
- すべての作業がクライアントによってコミットおよびロールバックされるため、作業が失われる可能性がない (整合性は、ソリューション 1 とソリューション 2 の両方よりも高い)
|
ストアド プロシージャによって取得されたロックは、クライアントがコミットまたはロールバックするまで解放されない (並行性はソリューション 1 およびソリューション 2 より低い) |