問題タブ [transaction-isolation]

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?

XA (2 フェーズ) トランザクションを使用しています。Log クラスと Entity Manager を使用して、1 つのログ テーブルにログを記録したいと考えています。EJB セッション Bean 内の私のメソッドは次のようになります。

「外部」トランザクションから独立した、分離された（自律的な）トランザクションでそれを行いたいです。@TransactionAttribute(value = TransactionAttributeType.REQUIRES_NEW)メソッド名の前にandを追加しようとしましたが@TransactionAttribute(value = TransactionAttributeType.NOT_SUPPORTED)、機能しません。

EJB3 メソッドを呼び出す前に、次のようなユーザー トランザクションを作成します。

コミットが完了したかどうかに関係なく、ログに記録したい。方法？

よろしく

以下の記述：

このSQLエラー3960が表示されます：

更新の競合により、スナップショット分離トランザクションが中止されました。スナップショット分離を使用してデータベース 'myDatabase' のテーブル 'dbo.Companies' に直接または間接的にアクセスし、別のトランザクションによって変更または削除された行を更新、削除、または挿入することはできません。トランザクションを再試行するか、更新/削除ステートメントの分離レベルを変更してください。

私が理解している限り、エラーメッセージから、dbo.Companies別の接続が変更されている間は、テーブルを更新、削除、または挿入しないでくださいdbo.Companies。

しかし、別のテーブルdbo.Changes( への外部キーを持つdbo.Companies) に新しい行を挿入していて、 で参照されている行を削除していなかったのに、主キーではなく でdbo.Companies行を更新しただけだったのはなぜですか? dbo.Companiesこれはうまくいくはずですよね？(SQL Server のバグですか?)

アップデート：

テーブルは次のようになります。

2番目の更新は行っています: