|
ほかのクライアントがレコードのロックに遭遇する可能性が高くなるリスクを負っても、作成するアプリケーションで確実に更新を行うことを優先する必要がある場合は排他的カーソルを使用します。
以前のバージョンの Pervasive PSQL OLE DB プロバイダーでは、排他的カーソルを使用できる ADO パラメーター adLockPessimistic がサポートされていませんでした。
現在は、このパラメーターを Pervasive の接続文字列の拡張機能と共に使用して排他的カーソルを持つアプリケーションを作成することができます。
OLE DB 仕様では排他的カーソルを、「最新のフェッチによって単一行に行われた変更が並行性違反のために失敗しないことを保証するカーソル」として定義しています。レコードセットを開いた後、バッチ更新されるまではしばらく時間がかかります。排他的カーソルを使用することは、この時間のギャップのために発生する並行性の問題を軽減する 1 つの方法です。
プロバイダーごとに行レベルのロックの実装が異なるので、OLE DB 仕様の排他的カーソルの定義は意図的に明確にされていません。ここでは一般的な 2 つの実装について説明します。
たとえば、次のように連続したイベントがあるとします。
開発者から見た場合の 2 つアルゴリズムの違いは、アルゴリズム(a)では読み取りロックを使用し、アルゴリズム(b)では更新ロックを使用しているという点です。次の表では、これら 2 つのアルゴリズム間の動作の違いについてまとめています。
ロック タイプ
|
動作
|
---|---|
読み取りロック
|
読み取るたびに行をロックします。
最初の Move メソッドで行のロックを解除します。
次の行をロックします。
|
更新ロック
|
データが変更されたときに行をロックします。
Update メソッドを呼び出したときに行のロックを解除します。
|
読み取りロックを使用することで、開発者は行を読み込んだときに並行性エラーを懸念することなく確実に更新を行うことができます。ただし、これは読み取る行を常にロックします。更新ロックではデータが変更された場合に行をロックするだけです。ただし、並行性エラーが発生するのはより遅くなる可能性があります。
このアーキテクチャの変更の詳細については、「OLE DB プロバイダーのアーキテクチャ」を参照してください。
Pervasive の排他的カーソルの実装によって、希望する動作を選択することができます。接続文字列内の排他的カーソルに関するパラメーターは次のとおりです。
Open メソッドの間に、この接続文字列オプションと、排他的カーソルを指定する ADO パラメーター adLockPessimistic を併用します。
接続文字列内で Pessimistic Read Lock=True
を使用すると、読み取りロックを実行します。次にそのサンプル接続文字列を示します。
更新ロックを実行する場合は、Pessimistic Read Lock の値を False に変更します。
次の表では、排他的カーソル オプションを使用する効果についてまとめています。
Pessimistic Read Lock=
|
動作
|
---|---|
True
|
読み取り時にレコードをロックします。
既にロックされていた場合はエラーを返します。
|
False
|
更新時にレコードをロックします。
既にロックされていた場合はエラーを返します。
|
次の Visual Basic サンプル コードの一部では、読み取りロックの排他的カーソルを使用して DEMODATA サンプル データベースの Course テーブルを開きます。
Public myRecordSet as ADODB.Recordset myRecordSet.CursorLocation = adUseServer myConnString = "Provider=PervasiveOLEDB;Data Source=DEMODATA;Pessimistic Read Lock=True" myRecordSet.Open "Course",myConnString, adOpenDynamic, adLockPessimistic, adCmdTableDirect myRecordSet.MoveFirst ' 最初のレコードがロックされます
|