フローを通過する単一のメッセージの存続期間より長い期間に渡ってデータを保管することが望ましい場合があります。その方法の 1 つとして、データベースにデータを保管するというものがあります。この方法は、長期の持続性とトランザクション特性の点では優れていますが、アクセス (特に書き込みアクセス) は低速になります。
代わりに適切な「存続期間の長い」ESQL データ・タイプを使用し、一定期間に渡ってデータのメモリー内キャッシュを提供できます。これならデータベースを使った場合よりもアクセスがずっと高速になりますが、持続性が短くなり、トランザクション特性がなくなるという犠牲が伴います。
存続期間の長い変数を作成するには、DECLARE ステートメントで SHARED キーワードを使用します。
Message Routing サンプルは、DECLARE ステートメントを使用して共用変数を定義する方法を示しています。このサンプルは、ルーティング情報をデータベース表に保管する方法、および共用変数を使用してメモリー内のデータベース表をメッセージ・フローに保管してパフォーマンスを改善する方法を示しています。
存続期間の長いデータ・タイプは長期に渡って存続し、ノードを通り抜ける単一のメッセージの存続時間を上回ります。以下の表で説明されているように、このタイプは複数のスレッドの間で共用され、メッセージ・フローの存続期間 (厳密に言えば、メッセージ・フローへの構成変更から次の構成変更までの間) 存在します。
有効範囲 | 存続期間 | 共用 | |
---|---|---|---|
存続期間の短い変数 | |||
スキーマおよびモジュール | ノード | ノード内のスレッド | なし |
ルーチンのローカル | ノード | ルーチン内のスレッド | なし |
ブロックのローカル | ノード | ブロック内のスレッド | なし |
存続期間の長い変数 | |||
ノード共用 | ノード | ノードの存続期間 | フローのすべてのスレッド |
フロー共用 | フロー | フローの存続期間 | フローのすべてのスレッド |
これらのデータ・タイプの典型的な使用法として、データ表がフローに対しては「読み取り専用」である場合に、そのフローの中でこうしたデータ・タイプを使用するというものがあります。表データは実際には静的ではありませんが、フローがこれを変更することはありません。表データに何らかの変更が加えられるまでの間に、何千ものメッセージがフローの中を移動します。
一例として、1 日のクレジット・カードの取り引きが入った表があります。この表は毎日作成され、その日のメッセージはこの表に対して実行されます。それからフローが停止し、表が更新され、次の日のメッセージが実行されます。この種のフローの場合、メッセージごとにデータベースから読み取りを行うよりも、表データをキャッシュに入れた方が、ほぼ確実にパフォーマンス向上が見込めます。
これらのデータ・タイプの別の使用法として、複数のメッセージからのデータの集計と統合があります。