9

楽観的ロック戦略を使用すると、以下のような同時実行性の問題を解決できます。

| | 最初の取引開始 |
| | | |  
| | 行を選択 |
| | | | 2番目のトランザクションが開始されました
| | バージョンチェックで行を更新 |
| | | | 同じ行を選択
| | トランザクションをコミット |
| | | | バージョン チェックで行を更新する
| | | |  
| | | | バージョンがダーティであるため、ロールバックします

しかし、非常にまれなケースですが、2 番目のトランザクションでの更新が、最初のトランザクションでの更新の後、トランザクションのコミット前である場合はどうなるでしょうか?

| | 最初の取引開始 |
| | | | 2番目のトランザクションが開始されました
| | 行を選択 |
| | | | 同じ行を選択
| | バージョンチェックで行を更新 |
| | | | バージョン チェックで行を更新する
| | トランザクションをコミット |
| | | | バージョンがダーティなのでロールバックします // そうでしょうか?
| | | |  
| | | |

最初のトランザクションがまだコミットされていないため、2 番目のトランザクションの更新で「ダーティ」バージョンを読み取ることができないという実験を行いました。この場合、2 番目のトランザクションは失敗しますか?

4

2 に答える 2

3

あなたの質問では、実際に使用しているデータベース システムについては言及されていませんでした。そのため、あなたのシステムの詳細についてはわかりません。

しかし、いずれにせよ、オプティミスティック ロック システムでは、プロセスが update ステートメントを実行するときに行のバージョンをチェックすることはできません。

完全にシリアライズ可能で分離されたトランザクションの場合、各プロセスは、コミット時に、検査および変更したすべての行の行バージョンをアトミックにチェックする必要があります。したがって、2 番目のシナリオでは、右側のプロセスは、コミットを試行するまで競合を検出しません (右側のプロセスに含めなかったステップ)。コミットしようとすると、競合が検出されてロールバックされます。

于 2013-06-03T06:28:07.737 に答える