問題タブ [isolation-level]

「繰り返し可能な読み取り」を使用すると、ファントム読み取りを生成できるはずですが、どのようにしたらよいでしょうか。CSの学生を教える例として必要です。

インデックス付けされていないフィールドxで「SELECT...WHERE x <= 888」を作成し、上限888が存在しないようにしてから、別の接続で888のすぐ下の値を持つ新しい行を挿入する必要があると思います。

それが機能しないことを除いて。非常に大きなテーブルが必要ですか？または、他の何か？

私がこれを調査しているときに出くわしたドキュメントは、他のデータベースに対してそれを行う方法は、クエリで複数のステートメントを使用することであることを示しています。

残念ながら、Python DB API（またはこの実装だけでしょうか？）は単一のクエリ内で複数のレコードセットをサポートしていないため、これを行っても結果は得られません。

過去にこれで成功した人はいますか？

どのシナリオでSERIALIZABLE分離レベルを使用しますか？ウェブサイトで、トランザクションを完全に分離したい場合は、通常、これを使用するという回答をいくつか見ました。

あなた自身の経験から知りたいのは、これをプロジェクトで使用したとき、またはこれが他のプロジェクトで使用されているのを見たとき、他の分離レベルでは満たされていない特定の要件は何かということです。 ？

トランザクションは、通常のようにサービスレベルで定義されます。

ただし、場合によっては、より高いSERIALIZABLEの分離レベルを必要とするDAOメソッドがあります。

ただし、SERIALIZABLE分離レベルが必要かどうかの知識は、DAOメソッドにカプセル化されているため、サービスメソッドはこれを知る必要はありません。

DAOメソッドレベルでSERIALIZABLE分離レベルを適用するにはどうすればよいですか？Springの分離レベルを特定する方法すら見つかりません。

SQL2008サーバーに接続するVB.netCFアプリがあります。トランザクションを実装しようとしていますが、トランザクションの開始時にコードを壊すと、テーブルに対して特定の読み取りクエリを実行できません。たとえば、id<>123のテーブルからすべてのレコードを選択しても値は返されません。ただし、select * from stockは、作業中の行を除くすべての値を返します。

アプリケーションは、Weblogicアプリケーションサーバー10.0によって提供されるデータソースを使用して、直接JDBCを介してメインフレームDB2にアクセスします。

1. 可能であれば、Weblogicでデータソースのトランザクション分離レベルを設定するにはどうすればよいですか。

2. アプリケーションが接続自体にトランザクション分離レベルを設定せず（デフォルトに設定され、「読み取りコミット」であると思います）、SQLステートメントのサフィックス「withUR」を使用する場合、ステートメントは次のように実行されます。 「コミットされていない読み取り」？

3. アプリケーションがDB2で取得するロックを見つける最も簡単な方法は何ですか？これは、多数のアプリケーションで使用されるメインフレームDB2インスタンスです...

一部の行を削除し、Java の条件に基づいてテーブルを更新しているときに、以下のエラーが発生します。私のデータベースは PostgreSQL 8.4 です。以下はエラーです: エラー: 重複したキー値が一意の制約 "xak1fact_dim_relationship" に違反しています

この問題を引き起こすコードは次のとおりです。

最初の削除ステートメントは正常に実行されましたが、更新の実行中に上記の例外がスローされています....! SQLServer、Oracle、および DB2 をサポートしており、同じコードが他の DB でも問題なく動作します。ちなみに、これらのステートメントを READ_COMMITTED トランザクション レベルで実行し、その間に何かが失敗した場合は安全にロールバックするように自動コミットをオフに設定しています。上記のコードを autocommit true で実行すると、コードは正常に動作します! しかし、そうすべきではありません。PostgreSQL の複数バージョン同時実行制御機能が疑わしいのですが、分離レベルの設定が間違っていますか? できるだけ早く私を助けてください。あなたが欲しい情報は何でも提供できます。

単純な質問であることを願っていますが、まともな答えをすぐに見つけられなかった質問です。PostgreSQL (具体的には、バージョン 9.0.4) のストアド プロシージャ (ユーザー定義 DB 関数) は、それ自体がトランザクションである SELECT ステートメントを介して呼び出されるため、本質的にトランザクション対応であると私は確信しています。では、ストアド プロシージャの分離レベルはどのように選択すればよいのでしょうか。他の DBMS では、目的のトランザクション ブロックは、目的の分離レベルがオプションのパラメーターである START TRANSACTION ブロックにラップされると思います。

具体的な例として、私がこれをやりたいとしましょう：

そして、この関数が常にシリアライズ可能なトランザクションとして実行されるようにしたいと想像してみてください (はい、はい、PostgreSQL SERIALIZABLE は適切にシリアライズ可能ではありませんが、それは重要ではありません)。として呼び出す必要はありません

では、必要な分離レベルを関数にプッシュするにはどうすればよいでしょうか? マニュアルBEGINにあるように、ステートメントに分離レベルを入れることはできないと思います

PL/pgSQL でステートメントをグループ化するための BEGIN/END の使用を、トランザクション制御のための同様の名前の SQL コマンドと混同しないことが重要です。PL/pgSQL の BEGIN/END はグループ化専用です。トランザクションを開始または終了しません。関数とトリガー プロシージャは常に、外部クエリによって確立されたトランザクション内で実行されます。実行するコンテキストがないため、そのトランザクションを開始またはコミットすることはできません。

私にとって最も明白なアプローチSET TRANSACTIONは、関数定義のどこかで使用することです。たとえば、次のようになります。

これは受け入れられますが、これが機能することに依存できるかどうかは明らかではありません。のドキュメントはSET TRANSACTION言う

START TRANSACTION または BEGIN を事前に指定せずに SET TRANSACTION を実行すると、トランザクションがすぐに終了するため、効果がないように見えます。

単一のステートメントを呼び出すとSELECT add_new_row('foo');(自動コミットを無効にしていない場合)、SELECT がセッションのデフォルトの分離レベルで単一行のトランザクションとして実行されることが予想されるため、これは私を困惑させます。

マニュアルには次のようにも書かれています。

トランザクションの最初のクエリまたはデータ変更ステートメント (SELECT、INSERT、DELETE、UPDATE、FETCH、または COPY) が実行された後は、トランザクション分離レベルを変更できません。

したがって、関数がより低い分離レベルのトランザクション内から呼び出された場合はどうなるでしょうか。たとえば、次のようになります。

おまけの質問: 関数の言語によって違いはありますか? PL/pgSQL では、プレーン SQL とは異なる分離レベルを設定しますか?

私は標準と文書化されたベスト プラクティスのファンです。

SQL Server 2005のデフォルトの分離レベルは何ですか？どのシナリオで変更しますか？また、デフォルトの分離レベルについての説明はほとんどありません。

期待してくれてありがとう

Hallo,

I want to get data into a database on a multicore system with ative WAL using JDBC. I was thinking about spawning multiple threads in my application to insert data parallely.

If the application has multiple threads I will have to increase the isolation level to Repeatable Read which on MVCC-databases should be mapped to Snapshot isolation.

If I were using one thread I wouldn't need isolation levels. As far as I know most Snapshot isolation databases analyze the write sets of all transaction that could have a conflict and then rollback all but one of the real conflict transactions. More specific I'm talking about Oracle, InnoDB and PostgreSQL.

1.) Is this analyzing of the write sets expensive?

2.) Is it a good idea to multithread the inserts for a higher total throughput? Real conflict are nearly impossible because of the application layer feeding the threads conflict free stuff. But the database shall be a safety net.