悲観的ロックと楽観的ロックの簡単な説明

悲観的ロックは、名前が示すとおり、非常に悲観的です。データを取得しに行くたびに、他の人がそのデータを変更すると考えて、データを取得するたびにロックします。 , そのため、他の人がこのデータを取得すると、ロックが取得されるまでブロックされます。このようなロック メカニズムの多くは、行ロック、テーブル ロック、読み取りロック、書き込みロックなど、従来のリレーショナル データベースで使用されており、操作前にすべてロックされます。

最も一般的に使用されるのは select... for update です。これは、トランザクションがコミットまたはロールバックされる前に選択の結果行をロックする行ロックです。他のトランザクションは、これらの行に対して更新、削除、または更新操作を実行することはできません。

楽観的ロック, 名前が示すように、非常に楽観的で、データを取得するたびに、他の人がデータを変更しないと考えてロックされません。この期間中はデータを自由に利用することができ、他の人に読み込まれますが、更新する際にはこの期間内に他の人がデータを更新したかどうかを判断し、バージョン番号などの仕組みを利用することができます。

バージョン番号メカニズムは、オプティミスティック ロックの最も一般的に使用される方法です。これは、テーブルにバージョン番号フィールドを追加することです。更新する前に、それを確認してバージョン番号を取得し、それを where として更新します。 update文の条件 Javaバックグラウンドで取得した更新番号の場合、バージョン番号取得後、更新前にデータが変更されている場合、最終的に更新されたデータは0個のため更新に失敗します。が 0 の場合は、更新が失敗し、同時実行の問題が発生したことを意味します。その後、具体的な対処を行ってください。

たとえば、2 人が同時に特定のデータを変更すると、プロセスは次のようになります:

オペレーター A は次のように動作します:

select id, balance, version from table where id=“1”;

クエリ結果: id=1, Balance=1000 , version=1

update table set balance=balance+100, version=version+1 where id=“1” and version=1;

実行後、返された更新結果は 1 で、1 つのアイテムが更新されたことを示します。データベース内の結果は次のようになります: id=1, Balance=1100 、version=2

操作 オペレーター B は次のように動作します:

select id, balance, version from table where id=“1”;

クエリ結果: id=1、balance=1000、version=1、オペレーター A がまだ変更していないことを示します。

update table set balance=balance-50, version=version+1 where id=“1” and version=1 ;

確認すると、オペレーター A はまだ変更していません。更新するときは、オペレーター A が先に変更に成功しているため、データベース内の実際の値は id=1、balance=1100 になります。 、version=2,

オペレータ B もバージョン番号を 1 つインクリメントし (version=2)、データベースにデータを送信しようとします (balance=950) が、この時点では id=1 のデータは送信されません。 " および version=1 が見つかりません。

したがって、更新は失敗し、実行結果は 0 となり、データが正常に更新されなかったことを示します。

ここでもう一度確認してください。結果は、オペレーター A が操作を完了した後の結果のままです。

select id, Balance, version from table where id="1";

Query結果: id=1、balance=1100、version=2

以上がバージョン番号の仕組みを自分で実装する原理ですが、実際に使用するバージョン番号の仕組みはデータベース自体が提供する仕組みです。更新されたバージョン番号が最新でないことが判明した場合、最新のものは拒否されます。

以上が悲観的ロックと楽観的ロックの簡単な説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。