問題タブ [transaction-isolation]

私のケースのシナリオは、挿入のみを行うプロシージャにパラメーターを渡します。ただし、2 つのスレッドが同じ値を渡そうとする場合があります。

例外をスローせずに、最小限のロックでこの状況を処理するにはどうすればよいですか?

私のパフォーマンス要件は、1 秒あたり少なくとも 10,000 回の挿入です。

編集:列は一意です。タイムスタンプは、挿入前に変更 (調整) される場合があります。

さて、私は、最も重要な問題の1つがデータベースの一貫性である割り当て[ミニプロジェクト]を取得しました。このプロジェクトは、複数のユーザーがプロジェクトにアクセスして操作できるようにするWebアプリケーションです。小さなテーブルセットへのクエリと更新の同時実行が期待できます。それらの一部は相互に接続されています（外部キーを使用）。

データベースの一貫性を可能な限り維持するために、分離レベルを使用することをお勧めします。それらについて少し（多分十分ではない？）読んだ後、私にとって最も有用なものはREADCOMMITTEDとSERIALIZABLEであると思いました。

クエリは次の3種類に分けることができます。

1. クエリの取得
2. クエリの更新
3. コンボ

1つ目は、もちろんデータの一貫性が必要です。ダーティデータやコミットされていないデータなどを表示したくないので、これらのクエリにはREADCOMMITTEDを使用することを考えました。クエリの更新については、SERIALIZABLEを使用するのが最善の選択肢だと思いましたが、少し読んだ後、迷子になりました。コンボでは、おそらくDBから読み取り、更新が必要かどうかを判断する必要があります。これらの2〜3回の呼び出しは同じトランザクションで行われます。

これらの各クエリオプションで使用する分離レベルについてアドバイスを求めたかった。タイプごとに異なる分離レベルを検討する必要がありますか？またはただ1つに固執しますか？

MySQL5.1.53とMySQLJDBC3.1.14ドライバーを使用しています（要件... JDBCバージョンを選択しませんでした）

あなたの洞察は大歓迎です！

編集：

デフォルトレベルのように見えるREPEATABLEREADを使用することにしました。それが正しい方法かどうかはわかりませんが、共有モードでのロックとクエリの更新のための繰り返し読み取りは正常に機能するはずです...

皆さんはどう思いますか？

Serializable Isolation Level に関するPostgreSQL のマニュアル ページには、次のように記載されています。

[同様に] Repeatable Read レベルでは、このレベルを使用するアプリケーションは、シリアル化の失敗によるトランザクションの再試行に備える必要があります。

Repeatable Read または Serializable レベルでシリアライゼーション エラーが発生する条件は何ですか?

実行中の 2 つのインスタンスでシリアライゼーションの失敗を誘発しようとしましたpsqlが、トランザクションが一方のインスタンスによってコミットされたにもかかわらず、もう一方のインスタンスがシリアライズ可能なレベルのトランザクション内でコミットされ、もう一方のインスタンスがその変更をコミットすることに成功しました。どちらもレコードをテーブルに挿入しただけなので、もっと複雑なことを試す必要があるかもしれません。

基本的に、シリアライゼーションが失敗した場合に何が起こるか、およびシリアライゼーションの失敗がどのように発生するかを理解しようとしています。

Tomcatの2つの別々のインスタンスで実行されているタスクスレッドがあります。タスクスレッドは、特定のwhere条件で（selectを使用して）TASKSテーブルを同時に読み取り、いくつかの処理を実行します。

問題は、両方のスレッドが同じタスクを選択することがあるため、タスクが2回実行されることです。私の質問は、TASKSテーブルから同じデータセットを読み取らないように両方のスレッドを作成するにはどうすればよいですか？

SQL Serverのトランザクション分離レベルを使用すると、ダーティリードなどの特定の不要な同時実行の問題を回避できます。

私が今興味を持っているのは更新が失われることです。2つのトランザクションが、誰にも気付かれることなく互いの更新を上書きする可能性があるという事実です。これを回避するために、少なくともどの分離レベルを選択する必要があるかについて、矛盾するステートメントを見たり聞いたりします。

Kalen Delaneyは、「SQL Server Internals」の本で次のように述べています（第10章-トランザクションと同時実行性-592ページ）。

Read Uncommitted分離では、失われた更新を除いて、前述のすべての動作が可能です。

一方、クラスを提供する独立したSQL Serverトレーナーは、更新の損失を回避するために、少なくとも「繰り返し可能な読み取り」が必要であると教えてくれました。

それで、誰が正しいのですか？なぜ？？

私は次のようなコードを持っています：

これは機能しません。クエリをテストしました。データがコミットされると効果的に機能しますが、コミットされていない場合、分離レベルがreaduncommittedに設定されている場合でも、ダーティリードでチェックできないという問題があります。これはテスト方法であるため、データベースに情報をコミットすることは決してできないため、情報にアクセスできない理由を理解したいと思います。
ありがとう！

これが全部です

....。

このarticaleによると、シリアル化可能な分離レベルは、行に対して読み取りロックと範囲ロックを実行します。したがって、あるトランザクションSELECTでいくつかの行（または行）に対してステートメントを実行すると、同じ行（またはその行のサブセット）をクエリしようとする別のトランザクションは、最初のトランザクションがコミットまたはロールバックするまでロックされます。右？しかし、オラクルではそのようなシナリオを実行しようとしましたが、2番目のトランザクションはロックされていません。最初のトランザクションでコミットを実行するまでロックされないのはなぜですか？

I've heard about many application developers having a bit of trouble in regards to race conditions in database processing. A typical example goes something like this:

• User 1 selects a field, say, numStock, which is 3
• User 2 also selects numStock, which is still 3
• User 1 decrements numStock (in the app), and sets it to 2 in the database.
• User 2 also decrements numStock (in the app), and sets it to 2 in the database.

In this example, the numStock field should have become 1, but it was set to 2 instead due to the race between users.

So of course locks can be used, but I've thought of another way of handling this - passing all row details as WHERE criteria. Let me explain...

In the example above, the SQL codes might look like this:

//select

//update

My idea for resolving the race:

//select

//update

Thus, the query checks if the data has changed since it SELECT-ed the data. So my question is: (1) Would this [always] work? and (2) is this a better option compared to database locking mechanisms (eg, MySQL Transactions)?

Thanks for your time.

Java アプリケーションで、一連の DB ステートメントをアトミックかつ分離された方法で実行する必要があります。たとえば、アプリケーションは、あるテーブルからデータ行を読み取り、別のテーブルのデータ行を更新する必要があります。

トランザクション管理は、上記のように、接続に対して自動コミットを false に設定し、後で明示的にコミットすることによって実現されます。しかし、上記のコードはマルチスレッド環境でも実行できます。また、2 つの DB ステートメント (選択と更新) を相互排他的に全体として実行することも必要です。

以下に示すように、そのメソッドで共有 Java Lock オブジェクトを使用する考えがあります。

クラスでは、

メソッドでは、

問題を解決する能力があるようです。ただし、これがベストプラクティスであるかどうか疑問に思っており、これに対するより良い代替手段 (フレームワークなど) はありますか?

If two transactions (both at RR isolation level) ask for the same item which is 2nd-level cached, and then they modify and store this item. Now, for reading that item, they did not run any SQL because it's cached; so in this case, will they actually start a data base transaction? And when they commit their changes, will they run into lost update problem?