問題タブ [transaction-isolation]

種類は異なるが同じタイプ (同じクラス、同じテーブル) のオブジェクトのシリアル番号を生成するソリューションを実装する必要があります。さらに、シリアル生成のルールは実行時に定義されます (開始シリアル、最大数など)。私は MySQL を使用していますが、休止状態の MySQL5Dialect はシーケンス生成をサポートしていないため、各行が異なる種類のオブジェクトのシーケンスであるシーケンス テーブルを使用してこの機能を実装することにしました。

値をインクリメントするdaoを作成しました：

そして、これはサービス層から次のように呼び出されます。

私はすべてを試しました: 分離レベルをIsolation.SERIALIZABLEに設定し、プログラムでメソッド内のトランザクションをコミットし、それにsynchronizedキーワードを追加し、ロック要求も追加しましたが、分離レベルが既に設定されているため、廃止されたと思います。

それでも、100 個のスレッドを作成し、それぞれからこのメソッドを 60 回呼び出すと、nextVal列の値は 6000 ではなく約 4000 になります。

ここで非常に基本的なことが欠けていると思われますが、これが期待どおりに機能するために必要なものを見つけることができません。

ヒントをありがとう！

私はそれについていくつかの研究を開始しているので、mysql でのトランザクション分離とは何か、そしてその利点を教えてください。これはそれについて取得するものです

デフォルトの分離レベルが READ_COMMITTED であり、読み取りが反復不可能であることは知っていますが、これが意味するすべてを理解しているかどうかはわかりません。

スレッド A が組み込みデータベースでトランザクションを開始し、スレッド B がトランザクションを開始してコミットした場合、スレッド A のトランザクション内の後続の読み取りでスレッド B のトランザクションの影響が見られることが保証されているか、または単に可能ですか?

Teradat 14 .NET プロバイダーを使用しています。単一のトランザクションで次の SQL を実行したい:

私が遭遇したこの問題は、削除は瞬時に行われますが、挿入には数秒かかるということです。削除の後、挿入がコミットされる前に (挿入が実行される前ではなく) 選択が行われた場合、行は返されません。SELECTしたがって、トランザクションがコミットされるまで、 両方のステートメントの結果が他のステートメントから見えるようにしたくありません。IsolationLevel.Snapshot私が望むものに最もよく一致する説明があります：

Reduces blocking by storing a version of data that one application can read while another is modifying the same data. Indicates that from one transaction you cannot see changes made in other transactions, even if you requery.

問題は、Teradata 14 がこのタイプのトランザクションをサポートしていないように見えることです。

The isolation level is not supported by this version of Teradata Database.

トランザクションがコミットされるまで、 deleteandの結果がinsert他のステートメントから見えないようにするにはどうすればよいですか?select

編集

dnoethの回答の後に使用しているコードは次のとおりです。私は Teradata セッションを使用しており、すべての SQL を単一の文字列に入れていますが、削除後、挿入が完了する前に選択が行われた場合、結果は返されません。あなたが提案したように私はそれをやっていますか？SQL でTdTransaction実行しているため、オブジェクトがないことに注意してください。bt;et;

一部のデータベース オブジェクトを JSON としてエクスポートしたいと考えています。エクスポート形式は、 の形式とほぼ一致しますが、各 dict には、 のそれぞれ、つまりインスタンスExample.objects.values(*columns)でメソッドを呼び出すことによって計算された値も含まれている必要があります。Example.objects.all()class Example(Model)

データベース クエリが 1 つだけの適切な辞書を作成するにはどうすればよいですか?

2 つのクエリ (私の現在のソリューション) を 1 つにまとめる動機は一貫性です。PostgreSQL に対して Django をデフォルトの「読み取りコミット」レベルで実行すると、2 つのクエリが一貫性のないデータを返す可能性があります。(パフォーマンスの向上も利点ですが、主な動機ではありません。)

2 つのパスが表示されます。

1. オブジェクトのクエリを実行し、Python コードでオブジェクトを辞書に変換します。
2. 辞書のクエリを実行し、Python コードで辞書をオブジェクトに変換します。

どちらが良いですか？何に気をつければいいですか？どちらかを正しく行うにはどうすればよいですか？Django は舞台裏で多くの複雑なことを行っています — とにかく、私が見たコードはいくぶん複雑に見えました — だから、よくわかりません: どのパスが最も堅牢でしょうか?

注：解決策はルックアップにまたがる必要があります。つまり、可能な出力__になりたいなどです。簡単なテストでは、これが行われないことが{"other_model__pk": 1}示唆されています。django.forms.models.model_to_dict

簡単な質問が 2 つあります。

1. SqlServerトリガーはデフォルトでアトミックですか?
2. そうでない場合、それを達成する方法は？

環境はシンプルです。データベースへの 2 つの異なる接続を持つ 2 人のユーザー (UserA と UserB と呼びましょう) がいます。両方の接続が同時にアクティブになります。

UserA が特定のテーブルに行を挿入すると、トリガーが起動されます (TriggerAtomic と呼びましょう)。TriggerAtomic が起動されたときに、TriggerAtomic が終了するまで UserB が何も実行できないようにする必要があります。明らかに、TriggerAtomic が終了するまで、他のトリガー、関数、手順は実行できません。

.deb を使用して Ubuntu システムに MySQL Workbench (community-6.2.3) をインストールしています。

Workbench セッションは、他のセッション (アプリケーション/コマンド ライン クライアント) によって行われたデータベースへの更新 (DML) を認識していないようです。
新しいセッションは、開始時にデータベースの正しいステータスを確認できますが、その後に発生した変更は表示されません。
ワークベンチでコミットした後、ワークベンチセッションがデータベースと同期しているようです。

Error Code: 1412. Table definition has changed, please retry transaction 別のセッションから作成したテーブルをクエリしようとすると、エラーが発生します。

ワークベンチ以外のセッションには、これらの問題はないようです。

構成か何かがありませんか？

アップデート：

これは、一部は予期された動作であり、一部はバグです。

私はautocommit mode を使用していません。この場合SELECT、最初の読み取り時に確立されたスナップショットを使用してステートメントが実行されます。
これは、MySQL Workbench で使用される REPEATABLE READ 分離レベルの動作です。

MySQL Workbench セッションのデフォルトの分離レベルを変更または設定する方法はありますか?

Workbench で実行した場合:

戻り値：

対照的に、コマンド ライン クライアントでは:

関連:
MySQL REPEATABLE-READ Workbench トランザクション レベルが設定されていません
MySQL Workbench とデフォルトのセッション分離レベル

Postgresql がシリアル化の失敗のためにトランザクションをロールバックすると、DBAPIError の形で SQL Alchemy にバブルアップします (新しいバージョンでは代わりに OperationalError が発生すると思います)。しかし、問題がシリアル化可能性 (トランザクションを再試行できる場合) なのか、それとも別の問題 (ユーザーにエラーを表示したい場合) なのかを知りたいです。

例外をキャッチして、その文字列表現を読み取ることができました。

しかし、これは堅牢ではなく、文字列をチェックするのは間違っていると思います。

より良い方法はありますか？

特定の例外が発生した場合 (私の場合は、基になるデータベースのシリアル化エラー)、Django ビュー関数を再実行したいと考えています。requestクライアントが URL を再要求したかのように、同じオブジェクトを含め、まったく同じパラメーターで実行したいと考えています。

ビューには多くのデータベースクエリがあり、それらのいずれかで例外が発生する可能性があります-クエリの1つだけを分離して再実行することはできません。そのため、ビュー関数全体をtry/except ブロックとループを成功するまで繰り返します。

しかし、そのような例外を発生させる可能性のあるビュー関数がいくつかあるので、一般的な解決策が必要です。また、特定の回数まで再試行してから失敗できるようにしたいと考えています。

簡単な解決策はありますか？

InnoDB's 私は分離レベルについて読んでいましたが、それはほとんどの場合理にかなっていますが、私が得られないのはなぜunrepeatable reads悪いことなのですか? 逆であってはいけませんか？

例えば：

たとえば、製品を販売するための在庫列があり、誰かが商品を購入するたびに列から 1 つの商品を取得するとします。Repeatable readまたはserializable分離レベルを使用すると、データの整合性が損なわれませんか?

例えば：

更新を実行するときに正しい値を使用しない限り?