次のノードがこのメッセージ・フローにある場合は、「トランザクション」プロパティーを設定します。
- Compute
- Database
- DataDelete
- DataInsert
- DataUpdate
- Filter
- Mapping
- Warehouse
「トランザクション」プロパティーには、次の値を設定できます。
- 自動
- メッセージ・フローの処理が完了したら、ノードが実行した更新、削除、または追加がすべてコミットあるいはロールバックされます。
メッセージ・フローが正常に完了した場合は、すべての変更をコミットします。
メッセージ・フローが正常に完了しなかった場合は、すべての変更をロールバックします。
メッセージ・フローによるすべての処理を整合したい場合には、この値を選択する必要があります。
- コミット
- メッセージ・フローのデプロイ先システムに応じて、異なるアクションが取られます。
同じメッセージ・フローの中に、
「自動」のトランザクション特性のノードと、
「コミット」のトランザクション特性のノードを混在させる場合、両方のノードが同じ外部データベースに対して操作を行うのであれば、別個の ODBC 接続を使用する必要があります。
一方の接続はメッセージ・フローが完了するまでコミットしないノード用、もう一方の接続は即座にコミットするノード用です。さもないと、即座にコミットするノードは、それより前の
「自動」ノードが実行した操作まで、すべてコミットしてしまいます。
注: z/OS 以外のプラットフォーム上では、それぞれのリレーショナル・データベースがこのモードの操作をサポートする場合もあれば、サポートしない場合もあります。
複数の ODBC 接続を定義すると、データベース・ロックの問題が起こることがあります。
特に、「自動」のトランザクション特性のノードが、データベース・オブジェクト (表など) をロックする操作 (INSERT または UPDATE など) を実行した場合、後続のノードが別の ODBC 接続を使ってこのデータベース・オブジェクトへのアクセスを試みると、無限ロック (デッドロック) が生じます。
2 番目のノードは、最初のノードが獲得したロックが解放されるのを待ちますが、最初のノードは、メッセージ・フローが完了するまで、操作をコミットすることも、ロックを解放することもありません。しかし、この場合にメッセージ・フローが完了することは決してありません。というのは、2 番目のノードが、最初のノードのデータベース・ロックが解放されるのを待っているからです。
このような状況を DBMS のデッドロック自動回避ルーチンで検出することはできません。
というのは、2 つの操作はブローカーを使って間接的に干渉し合っているからです。
この種のロックの問題を回避する方法が 2 つあります。
- コミットされていない (「自動の」) 操作が、別の ODBC 接続を使う後続の操作がアクセスしなければならないデータベース・オブジェクトをロックしないように、メッセージ・フローを設計する。
- 一定時間が経過したらロックを獲得しようとしても失敗するように、データベースのロック・タイムアウト・パラメーターを構成する。
ロック・タイムアウトが原因でデータベースの操作が失敗したら、例外がスローされ、ブローカーはこれを通常の方法で処理します。
特定の操作によってロックされるデータベース・オブジェクトについて、およびデータベースのロック・タイムアウト・パラメーターを構成する方法については、ご使用のデータベース製品の資料をご覧ください。