問題タブ [transaction-isolation]

私は以下の状況です。

MonthlySales永続オブジェクトを読み取り/更新できるスレッドがいくつかあります。問題は、これらのオブジェクトが存在しない可能性があり、要求に応じて動的に作成する必要があることです。
したがって、2 つの異なるスレッドが同じキー (つまり、同じ ID を持つ) に対応するエンティティを作成することになり、そのうちの 1 つがcommit に失敗します。私はこれが起こることを望んでいません。2 つのスレッドのうちの 1 つが競争に勝ち、もう 1 つが緩んで、オブジェクトがもう一方によって作成されるまで待ちたいと思います。

つまり、シリアル化されたトランザクションを実行したいのです。明示的な Java ロック (synchronizedブロック) を設定する必要がありますか?

私の現在のコードは次のとおりです。

手伝って頂けますか？

非反復読み取りとファントム読み取りの違いは何ですか?

Wikipediaの Isolation (database systems) の記事を読みましたが、いくつか疑問があります。以下の例では、何が起こるでしょうか:反復不可能な読み取りとファントム読み取り?

もう 1 つの疑問は、上記の例では、どの分離レベルを使用する必要があるかということです。なぜ？

私はある種のキューイングメカニズムを構築しています。処理が必要なデータの行とステータスフラグがあります。私はupdate .. returningそれを管理するために句を使用しています：

ネストされた選択部分は更新と同じロックですか、それともここに競合状態がありますか？もしそうなら、内側の選択は？である必要がありselect for updateますか？

あるトランザクションによって読み取られた行が別のトランザクションによって読み取られないという状況をどのように達成できますか?

columnA-F を持つテーブルの 1 つから、max(columnA). 最大値といくつかの計算に基づいて、他の挿入ステートメントを実行する必要があります。

シリアライズ可能な分離レベルでは、2 つのトランザクションが同じ最大値を読み取っています。これにより、1 つのトランザクションでロック待機が発生し、別のトランザクションでデッドロックが発生します。

MS SQLは、前のトランザクションが完了する（またはコミットされる）直前に別のトランザクションを開始する可能性があることに気付きました。次のトランザクションが始まる前に、トランザクションが最初に完了する必要があることを確認する方法はありますか？

私の問題は、SQLINSERTのほぼ直後にSQLSELECTを実行したいということです。私が今見ているのは、SELECTステートメントが実行されるとき。（非常に）最近挿入されたデータは返されません。

SQLプロファイラーを使用してこのシナリオをトレースすると、INSERTが完了する前にSELECTが発生するため、SQLINSERTとSELECTが同時に実行されることに気付きました。

私のこの問題を解決する方法はありますか？ありがとう！

トランザクション内の行の場合SELECT... FOR UPDATE、明らかに行への書き込みがブロックされますが、読み取りも禁止されますか? 行から読み取ることができるようにしたいので、答えが「はい」の場合、これを機能させるソリューションを提供できますか?

テーブルと、を指す外部キーを持つfoo_bar別のテーブルがあります。関連する行が削除されると、行はカスケード削除されます。spam_eggsfbfoo_barspam_eggsspam_eggs.fb

私はPostgreSQLを使用しています。

トランザクションでは、行SELECT... FOR UPDATEをロックするために使用しました。spam_eggsこのトランザクションの期間中に、別のトランザクションが私のロックされた行DELETE FROM...の関連を試みました。foo_barこれによりエラーがトリガーされますか、それとも元の更新トランザクションが終了するまで行がロックされるとクエリがブロックされますか？

PostgreSQL 9.1（または9.2）で実行される次のクエリについて考えてみます。

かなり長時間実行されるクエリだとします（たとえば、1分かかります）。

クエリの開始時に保持されるレコードが500万件ありbar = true、別のトランザクションでのこのクエリ中にテーブルに追加および削除された行がfooあり、一部の既存の行についてはbarフィールドが更新されます。

これは、上記の選択クエリの結果に影響しますか？

単一のトランザクション内の個別のステートメント間のトランザクション分離と可視性については知っていますが、実行中の単一のステートメントについてはどうでしょうか。

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

この例に関する私の質問は、クエリがデータベースにヒットしたときと関係があります。明らかに、最初のクエリで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

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