問題タブ [transaction-isolation]

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番目の更新は行っています:

私は以下の状況です。

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フィールドが更新されます。

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

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