更新を監視する表を指定した後、ttXlaNextUpdateまたはttXlaNextUpdateWait関数をコールして、トランザクション・ログから一連のレコードを返すことができます。コミット済トランザクションのレコードのみが、コミットされた順序で返されます。ttXlaAcknowledge関数を定期的にコールして、トランザクションの受信を確認する必要があります。これによって、不要になったパージ可能なレコードを判別できます。これらの関数は、トランザクション・ログ内のアプリケーションのブックマークの位置に影響を与えます(「XLAブックマークについて」を参照)。
注意: | ttXlaAcknowledge は高コストの処理のため、頻繁には使用しないでください。詳細は、「ttXlaAcknowledge」を参照してください。 |
ttXlaNextUpdateによって返されたトランザクション内の各更新レコードは、ttXlaUpdateDesc_t構造体で記述される更新ヘッダーで始まります。この更新ヘッダーには、レコードがトランザクションの最初のレコードか(TT_UPDFIRST)、最後のコミット・レコード(TT_UPDCOMMIT)を示すフラグが格納されています。また、更新ヘッダーは、更新によって影響を受ける表も識別します。更新ヘッダーの後には、データ・ストア内の表に対して行われた変更について記述する0(ゼロ)から2行の行データが続きます。
図3.5に、4つの更新レコードで構成されているトランザクションをログから返すttXlaNextUpdateへのコールを示します。返されたトランザクションの受信は、ttXlaAcknowledgeをコールすることで確認され、ブックマークが再設定されます。
注意: | この例は、説明を明確にするために簡略化されています。実際のXLAアプリケーションでは、ttXlaAcknowledgeをコールする前に、複数のトランザクションを読み取る可能性があります。 |
xlaSimple.c
デモでは、表の更新に対する監視は、ユーザーが停止するまで続行されます。
ttXlaNextUpdateWaitをコールする前に、トランザクション・ログから返されるレコードの最大数(MAX_RECORDS)および実際に返されるレコード数を保持する変数(records)を指定するのみでなく、返されるttXlaUpdateDesc_tレコードを保持するバッファへのポインタ(arry)を初期化します。また、ttXlaNextUpdateWaitをコールするため、トランザクション・ログ・バッファでレコードが見つからない場合に待機する秒数(FETCH_WAIT_SECS)も指定します。
次に、ttXlaNextUpdateWaitをコールし、これらの値を渡してarry内の一連のttXlaUpdateDesc_tレコードを取得します。例3.4に示すように、arry内の各レコードは、HandleChange関数に渡すことによって処理されます。すべてのレコードの処理後、ttXlaAcknowledge をコールして、ブックマークの位置を再設定します。
#define FETCH_WAIT_SECS 5
#define MAX_RECORDS 100
SQLINTEGER records;
ttXlaUpdateDesc_t ** arry;
int j;
while (!StopRequested()) {
/* Get a batch of update records */
rc = ttXlaNextUpdateWait(xla_handle, &arry, MAX_RECORDS,
&records, FETCH_WAIT_SECS);
if (rc != SQL_SUCCESS) {
/* 「XLAエラーの処理」を参照*/
}
/* Process the records */
for(j=0; j < records; j++){
ttXlaUpdateDesc_t *p;
p = arry[j];
HandleChange(p); /* Described in the next section */
}
/* After each batch, Acknowledge updates to reset bookmark.*/
rc = ttXlaAcknowledge(xla_handle);
if (rc != SQL_SUCCESS) {
/*「XLAエラーの処理」を参照*/
}
} /* end while !StopRequested() */
ttXlaNextUpdateまたはttXlaNextUpdateWaitによって返されるレコードの実際の数は、nreturned 出力パラメータで示されるように、maxrecords パラメータの値より小さい場合があります。図3.6に、例を示します。この例では、maxrecordsが10で、7つのレコードで構成されているトランザクションATおよび3つのレコードで構成されているトランザクションBTがログに含まれています。この場合、両方のトランザクションが同じバッチで返され、 maxrecords および nreturned の両方の値が10になります。ただし、ログ内のその次の3つのトランザクションは、11個のレコードで構成されているCT、2つのレコードで構成されているDTおよび2つのレコードで構成されているETになります。CTのコミット・レコードの前にDTのコミット・レコードが書き込まれるため、次にttXlaNextUpdateをコールすると、DTトランザクションの2つのレコードが返され、nreturnedの値は2になります。その次にttXlaNextUpdateをコールすると、XLAによって、CTトランザクションの合計レコード数がmaxrecordsを超えていることが検出され、このトランザクションのレコードが2つのバッチで返されます。1つ目のバッチには、CTトランザクションの最初の10個のレコード(nreturned = 10)が含まれます。2つ目のバッチには、CTトランザクションの最後のレコードおよびETトランザクションの2つのレコード(ETトランザクションの後のトランザクションのコミット・レコードが次の7つのレコード内で検出されない場合)が含まれます。
XLAは、レコードをメモリー・バッファまたはログ・ファイルから読み取ります(「XLAでレコードをトランザクション・ログから読み取る方法」を参照)。待機時間を最小にするために、メモリー・バッファからのレコードは使用可能になるとすぐに返されますが、バッファにないレコードはバッファが空の場合にのみ返されます。この設計によって、XLAアプリケーションでは、行われた変更を最小の待機時間ですぐに表示できます。トレードオフとして、ttXlaNextUpdateまたはttXlaNextUpdateWaitのmaxrecordsパラメータでリクエストした数より少ない数の変更が返される場合があります。
注意: | 一部のXLAアプリケーションでは、フェッチおよびレコード処理の手順を非同期にすることでパフォーマンスを向上できます。たとえば、1つのスレッドを作成してレコードのフェッチおよび保存を行ったり、1つ以上のスレッドを作成して保存したレコードを処理することができます。 |