以降のトピックでは、MicroKernel の並行制御方法について詳しく説明します。各トピックを読むときは、競合コードの表を参照してください。この表では、2 つのクライアントが同じファイルのアクセスまたは変更を行おうとする場合に発生する可能性のある競合のタイプをまとめています。この表はローカル クライアントのアクションを説明しています。

この表では、クライアント 1 は表の左端の列の略語によって識別されるアクションを実行し、次にクライアント 2 が表の上端の行の略語によって識別されるアクションのうちの 1 つを実行しようとします。

これらの略語によって表されるアクションについては、アクション コードで説明しています。

競合コードの表では、次のような前提条件があります。

クライアントはさまざまな種類のレコード ロックを明示的に要求できます。詳細については、ロックを参照してください。

トランザクションによって、データが消失する可能性が低くなります。ファイルに加える変更が多く、また、これらの変更が確実にすべて行われるか、まったく行われないようにする必要がある場合は、1 つのトランザクションにこれらの変更用の操作を取り込みます。明示的なトランザクションを定義すれば、MicroKernel に複数の Btrieve オペレーションを 1 つのアトミック単位として処理させることができます。トランザクション内にオペレーション群を取り込むには、Begin Transaction（19）オペレーションと End Transaction（20）オペレーションでこれらのオペレーションを囲みます。

MicroKernel には、排他トランザクションと並行トランザクションの 2 種類のトランザクションがあります。どちらの種類を使用するかは、変更するファイルに対して、ほかのクライアントからのアクセスをどのくらい厳しく制限するかにより決まります。MicroKernel では、ほかのアプリケーションやクライアントはトランザクションが終了するまで、どのようなトランザクション（排他または並行）にかかわる変更でも見ることができないことに留意してください。

MicroKernel には、明示的ロックと暗黙ロックの 2 種類のロックがあります。クライアントが Btrieve オペレーション コードにロック要求を含めることによって明確にロックを要求する場合、そのロックを明示的ロックと呼びます。しかし、たとえクライアントが明示的にロックを要求しない場合でも、MicroKernel はクライアントが実行した動作の結果として影響を受けたレコードまたはページをロックできます。この場合、MicroKernel が行うロックを暗黙ロックと呼びます。（暗黙レコード ロックと暗黙ロックを参照してください。）

このトピックでは、非トランザクション環境における明示的レコード ロックについて説明します。トランザクションがレコード ロックの使用にどのような影響を与えるかについては、並行トランザクションのレコード ロックを参照してください。

単一レコード ロックの場合と同様に、クライアントが複数レコード ロックで 1 つまたは複数のレコードをロックすると、ほかのクライアントはこれらのレコードに対して Update（3）または Delete（4）オペレーションを実行できません。ロックで説明しているように、ほかのクライアントは Get または Step オペレーションを使用して、これまでどおりロックされたレコードを読み取ることができます。

排他トランザクション（オペレーション 19）はファイル全体をロックするので、トランザクション内のレコード ロックは並行トランザクション（オペレーション 1019）にしか適用されません（トランザクションの種類の詳細については、ユーザー トランザクションを参照してください）。

並行トランザクションで単一レコード ロックと複数レコード ロックを解除するイベントは、非トランザクション環境のイベントに似ています。単一レコード ロックについては、単一レコード ロックを参照してください。複数レコード ロックについては、次の例外を除き、複数レコード ロックを参照してください。

クライアントがトランザクションの外部または並行トランザクション内からレコードの更新または削除を行おうとすると、MicroKernel はクライアントの代わりにそのレコードを暗黙にロックしようとします。排他トランザクションで、暗黙のレコード ロックが不要なのは、MicroKernel が Update または Delete オペレーションを実行する前にファイル全体をロックするからです（ファイル ロックを参照してください）。

MicroKernel は、オペレーションの実行中、ファイルの整合性を確保するために必要な暗黙レコード ロックおよびその他すべてのロックを正常に取得できる場合のみ、指定された Update または Delete オペレーションを実行します（暗黙ロックを参照してください）。

暗黙ロックが維持されていなかったら、レコード A に対するクライアント 1 の暗黙レコード ロックはなくなっているため、クライアント 2 はレコードを正常に読み取ってロックできてしまいます。しかし、クライアント 1 が新しいイメージをコミットしていないので、クライアント 2 はレコード A の古いイメージを読み取ります。クライアント 1 がレコード A の変更されたイメージをコミットするオペレーションを終了し、クライアント 2 がレコード A を更新しようとすると、そのレコードのクライアント 2 のイメージは無効となるので、MicroKernel はステータス コード 80「MicroKernel でレコード レベルの矛盾が発生しました」を返します。暗黙ロックのない例の例を参照してください。

Begin Transaction オペレーションでは、このバイアス値 500 をレコード ロックのバイアス値と組み合わせることができます。たとえば、1019 + 500 + 200（1719）を使用すると、Insert、Update、および Delete オペレーションの再試行が抑止されると同時に、単一レコードの読み取りノーウェイト ロックが指定されます。

トランザクションの外側または並行トランザクションの中から Insert、Update、または Delete オペレーションが発生する場合は、MicroKernel がクライアントの代わりに、これらの操作中に変更されるレコードを暗黙にロックしようとします（排他トランザクションでは、MicroKernel は Update や Delete オペレーションを実行する前にファイル全体をロックするため、暗黙のレコード ロックおよびページ ロックは必要ありません。Insert オペレーションの場合は、クライアントがまだファイルをロックしていなければ MicroKernel がファイル ロックを要求します。ファイル ロックを参照してください）。暗黙レコード ロックと同様に、暗黙ページ ロックは MicroKernel エンジンが行うため、クライアントは明示的に要求しません。

暗黙ページ ロックと明示的レコード ロックまたは暗黙レコード ロックは、互いにブロックに影響を与えません。クライアントは、操作対象のレコードが入っているページを別のクライアントが暗黙にロックしていたとしても、そのページ上のレコードを読み取り、ロックすることができます。ただし、これは暗黙レコード ロックで説明しているように、ロックするレコードが更新されたレコードと同じでない場合に限ります。逆に、クライアントはレコードを更新または削除した場合、それによって影響を受けるレコードが入っているデータ ページの中に、別のクライアントによってロックされたレコードが既に含まれていても、そのデータ ページを暗黙にロックすることができます。

MicroKernel は手順 7 で Update（3）オペレーションそのものを実行するときに、変更されたデータ ページとインデックス ページのコミットされていない新しいイメージをシャドウ ページとしてファイルに書き込みます。この時点で、MicroKernel はレコード B に対するクライアント 2 の明示的ロックを解除しますが、クライアント 2 は今し方取得した暗黙ページ ロックに加えて、レコード B の暗黙レコード ロックも保持します。クライアント 2 が手順 7 で Update（3）オペレーションを終了した後でも、クライアント 3 がまだレコード B に対する暗黙レコード ロックを取得できないのは、クライアント 2 がレコードに対する暗黙レコード ロックを今も保持しているからです。クライアント 3 は、その再試行を続ける必要があります。

手順 8 で、クライアントはまずレコード A に対する暗黙レコード ロックをうまく取得します。たとえレコード A のデータ ページが既にクライアント 2 でロックされていても、ページ ロックはレコード ロックをブロックしないので、ロックの競合はありません（暗黙ロックを参照してください）。次に、クライアント 1 はレコード A を含んでいるデータ ページの暗黙ページ ロックを取得しようとします。この試行は、データ ページが手順 7 でクライアント 2 によって既にロックされているため失敗します。Begin Concurrent Transaction（1419）オペレーションは 500 バイアスを指定していないため、MicroKernel はオペレーションを再試行します。クライアントがローカルである場合、MicroKernel はデッドロック検出も行います。

手順 7 で、クライアント 1 はファイルにアクセスした結果としてファイル 1 に対するファイル ロックを取得します（ファイル ロックを参照してください）。もし、直前の手順（たとえば手順 5 と 6 の間）でクライアント 2 がロック バイアスを持つオペレーションを使用してファイル 1 からレコードを読み取っていたら、手順 7 は失敗します。

手順 9 では、クライアント 1 がファイルをロックしているため、クライアント 2 は暗黙レコード ロックを取得できません。したがって、MicroKernel はクライアント 2 にステータス コード 85（ファイルがロックされている）を返します。クライアント 2 は直ちに制御を放棄し、クライアント 1 が手順 13 でトランザクションを終了または中止するまで、手順 9 を再試行しなければなりません（レコードが既にロックされている場合を参照してください）。

並行トランザクションまたは排他トランザクションの内側では、複数ポジション ブロックは変更されたページの同じビューを共有します。複数ポジション ブロック セット内の各ポジション ブロックは、そのセットのほかのポジション ブロックによって行われた変更であれば、変更がコミットされる前であっても、直ちにわかります。

たとえば、キー値として -2 を持つ Unlock（27）オペレーションは、指定されたポジション ブロックに属する複数レコード ロックのみを解除します。Close（1）オペレーションは、その実行時に指定された同じポジション ブロックに対して取得されたロックのみを解除します。同様に、クライアントがトランザクション内でポジション ブロックの最初のレコード ロック、ページ ロック、またはファイル ロックを取得したとき、MicroKernel はそのポジション ブロックに対して取得していた明示的レコード ロックのみを解除します。例 2 で、クライアント 1 がファイル 1、ファイル 2、ファイル 3 を開くのではなく、同じファイルを 3 回開いていた場合、また、クライアント 1 が最初の 2 つのポジション ブロックのみを使用してファイルにアクセスしていた場合、3 つ目のポジション ブロック用に取得した明示的ロックは、End Transaction オペレーション以降も変化しません。