問題タブ [transaction-isolation]

たとえば、次のコードを取り上げます（必要なものを含めるための単純な例であるため、機能の有用性の欠如は無視してください）。

この例に関する私の質問は、クエリがデータベースにヒットしたときと関係があります。明らかに、最初のクエリでPerson行がロックされ、次に低速のAPIを呼び出しています。これは、応答に3秒かかる可能性があり、行が3秒間ロックされる原因になります。私はこれを正しく理解していますか？トランザクションで遅いAPIヒットが発生した場合、すべての遅いAPIリクエストが完了するまでクエリの場所を移動しSELECT FOR UPDATEないと、これは一見明らかな効果があります一度に数秒間行をロックしない（私のアプリケーションの場合は避けられない）？または、私は誤解していて、どういうわけか、トランザクションが終了するまで、SQLのどれも実際にデータベースにヒットしませんか？select_for_update

@Transactional アノテーションだけでコードとトランザクションの実行を管理する方法について質問があります。正しくセットアップされた Spring アプリケーションと次のコードがあるとします。

次のシナリオが発生する可能性はありますか。

• 資金 == 100; 金額 == 100
• スレッド A が撤回に入る / トランザクション A が開始する
• スレッド A は、true と評価される isEnoughFunds を実行します
• スレッド B が撤回に入る / トランザクション B が開始する
• スレッド B は、true と評価される isEnoughFunds を実行します。
• スレッド A は reduceFunds を実行します / スレッド A は db レコードをロックします
• スレッド B は、スレッド A がトランザクションをコミットして書き込みロックを解放するのを待ちます。
• スレッド A が撤退を終了する / トランザクション A がコミットする
• スレッド B は reduceFunds を実行します / スレッド B は db レコードをロックします
• スレッド B は撤退を終了する / トランザクション B はコミットする
• 資金 == -100

これが可能である場合、どのようにそれを防ぎますか?

InnoDB を使用して MySQL にテーブルがあり、コミットされていない読み取りのトランザクション分離レベルを使用しています。@x示されているように設定するとロックが取得されるのはなぜですか?

別のプロンプトからこのテーブルを更新しようとすると、タイムアウト エラーが発生します。

私は Spring トランザクション管理を使用して、休止状態でアプリケーションを制御しています。スレッドの 2 つのインスタンスを使用して同時実行データベースにアクセスし、1 つのテーブルを変更します。値が確実に保存されるようにします。前の表は次のとおりです。

そして後の表：

メイン コードは 2 つのスレッドを開始します。

クラスServicoは次のとおりです。

クラス LivroQuantBoImpl には次のメソッドがあります。

そして私のSpring .confは次のとおりです。

そして、この実行時例外を実行しています:

なにが問題ですか？

データベースに対して2つの同時セッションを実行する（同時に2セットのトランザクションを実行する）必要があります。各トランザクションには、独自の開始トランザクションステートメントと終了トランザクションステートメントがあります。

トランザクション分離レベルを変更した後、2つの特定のセッションを同時に実行するようにデータベースに指示するには、どのステートメントを使用する必要がありますか？pg-adminを使用しています。

関数pg_sleepは、2セットのトランザクションを同時に実行するのに役立ちますか？

ありがとう！

同じアプリケーション内で異なるトランザクション分離レベルを使用することは可能ですか? たとえば、単純なクライアント リクエストには READ_COMMITTED を使用し、より複雑なリクエストには READ_REPEATABLE を使用したいと考えています。

コミットに関するさまざまな分離レベルについて知りたいです。また、行レベルとテーブルレベルのロックについても知りたいです。

家には居住者がいて、どの家にも 2 人の居住者が同じ高さを持つことはできないと仮定します。

1. ランダムな家を選ぶ
2. 家の現在の居住者のリストを取得する
3. リストを調べて、どれを保持、置換、削除、または追加するかを決定します
4. 新しいリストに同じ身長の居住者が含まれていないことを確認してください。
5. 既存のリストを新しいリストに置き換えます。必要に応じて削除、挿入、または更新します。

簡単に思えますが、50 個のスレッドがすべて同時にこれを実行しようとすると、複雑になります。私はUPDLOCK、ROWLOCKを選択（ステップ2）で使用して、更新する可能性のある占有者への更新をブロックしました。ただし、現在の居住者がなく、新しい居住者が追加されると、時々失敗します。失敗は常に一意の制約違反です。これは決して起こらないはずですが (手順 4 を参照)、実際に発生します。

手順 2 ～ 5 は、ReadCommitted 分離レベルを使用して TransactionScope 内で実行されています。

このようなシナリオの処理方法を定義するベスト プラクティス モデルはどこかにありますか?

ここでMVCCモデルのトランザクション分離について読みましたが、2つの質問がありました。

• MVCCはロックを使用しますか？私が理解した限りでは-いいえ、もしそうなら-
• この表はどういう意味ですか？

トランザクションに対してシリアル化可能なトランザクション分離ロックを設定しましたが、予期しない結果がいくつか見られます。

私のクエリは

ここで、col1 は主キーです。ここでは、col1 の値が 10,11,12....19,20 の行が更新/挿入のためにロックされています。where 条件では、col1>10 および col1<20 として条件を指定しましたが、それでも col1=10 および col1=20 の行がロックされます。

私が与えるなら

次に、col2 の値が 9 から 21 の行がロックされます。では、なぜ col1 の値が 9 と 21 でここでロックされるのでしょうか。

以下のクエリでは、テーブル全体がロックされます。ここで、col3 は非プライマリ カラムです。WHERE 条件のカラムがプライマリ キーでない場合、ロックを設定できませんか?