次の方法で共有


オプティミスティック コンカレンシー

オプティミスティック同時実行 は、トランザクション間の競合はほとんど発生しないというオプティミスティックな想定からその名前を導き出します。競合は、別のトランザクションが現在のトランザクションによって読み取られ、更新または削除されるまでの間にデータの行を更新または削除したときに発生したと言われます。 これは、アプリケーション開発者がこのような競合が一般的であると考えるペシミスティック同時実行 (ロック) とは反対です。

オプティミスティック同時実行では、行は更新または削除されるまでロック解除されたままです。 その時点で、行が再読み込みされ、最後に読み取られた後に変更されたかどうかを確認します。 行が変更された場合、更新または削除は失敗し、もう一度試す必要があります。

行が変更されたかどうかを確認するために、その新しいバージョンは、キャッシュされたバージョンの行に対してチェックされます。 このチェックは、SQL Server のタイムスタンプ列や行の各列の値など、行のバージョンに基づいて行うことができます。 多くの DBMS では、行バージョンはサポートされていません。

オプティミスティック同時実行は、データ ソースまたはアプリケーションによって実装できます。 どちらの場合も、アプリケーションは Read Committed などのトランザクション分離レベルを低くする必要があります。より高いレベルを使用すると、オプティミスティック同時実行を使用して得られるコンカレンシーの増加が無効になります。

データ ソースによってオプティミスティック同時実行が実装されている場合、アプリケーションは SQL_ATTR_CONCURRENCY ステートメント属性を SQL_CONCUR_ROWVER または SQL_CONCUR_VALUES に設定します。 行を更新または削除するには、位置指定された更新または削除ステートメントを実行するか、ペシミスティック同時実行の場合と同様に SQLSetPos を呼び出します。ドライバーまたはデータ ソースは、競合のために更新または削除が失敗した場合に SQLSTATE 01001 (カーソル操作の競合) を返します。

アプリケーション自体がオプティミスティック同時実行を実装する場合は、SQL_ATTR_CONCURRENCY ステートメント属性を行の読み取り SQL_CONCUR_READ_ONLY に設定します。 行バージョンを比較し、行バージョンの列がわからない場合は、SQL_ROWVER オプションを使用して SQLSpecialColumns を呼び出して、この列の名前を決定します。

アプリケーションが行を更新または削除するには、コンカレンシーを SQL_CONCUR_LOCK に増やし (行への書き込みアクセスを取得するため)、行の読み取り時に行のバージョンまたは値を指定する WHERE 句を使用して UPDATE または DELETE ステートメントを実行します。 その後行が変更された場合、ステートメントは失敗します。 WHERE 句が行を一意に識別しない場合、ステートメントは他の行も更新または削除する可能性があります。行のバージョンでは常に行が一意に識別されますが、行の値は主キーを含む場合にのみ行を一意に識別します。