`@ transaction.non_atomic_requests`にはどのような種類のリクエストが適していますか？

Question

transactionsをウェブ上で処理する一般的な方法は、各リクエストをトランザクション内にラップすることです。 Djangoでは、この動作を有効にする各データベースの設定でATOMIC_REQUESTSをTrueに設定できます。

このように動作します。ビュー関数を呼び出す前に、Djangoはトランザクションを開始します。応答が問題なく生成された場合、Djangoはトランザクションをコミットします。ビューが例外を生成すると、Djangoはトランザクションをロールバックします。

このトランザクションモデルの単純さは魅力的ですが、トラフィックが増加すると非効率的になります。すべてのビューのトランザクションを開くには、いくつかのオーバーヘッドがあります。

transactionsでラップする必要がないリクエストの場合は、@transaction.non_atomic_requestsデコレータを適用できます。

Django view.pyでは、いくつかのViewクラスとリクエストメソッドがあります。どのような要求が非アトムデコレータの良い候補になるかを決めるにはどうすればよいですか？

"gotchas"とは何が潜んでいるのですか？

私はPOSTの方法では良い候補を作ることができないか、.save()で何かを作ることができましたが、他に何を調べるべきですか？

Answer 1

残念ながら、一般的に適用可能なヒントや落書きなどはあまりありません。問題は単なるものです：この一連の操作では、実行する可能性のあるすべてのデータベース操作を考慮して、データベーストランザクションが正しく機能する必要がありますか？答えが「はい」（または不確かな場合）の場合は、トランザクションを使用します。もしそうでなければ、しないでください。

非常にアプリケーション固有の質問です。あなたの例を挙げると、save()にはトランザクションが必要な多くの状況があり、そうでないところでは多くの状況があります。私はただ座って、可能性を考えていく代わりのことは知らない。

最も重要なことは、特にisolation levelsというデータベーストランザクションをよく理解することです。実際には、オペレーションがREAD COMMITTED（Djangoのデフォルト）を使用しているときに、トランザクションの精神モデルがSERIALIZEDの分離レベルに一致するため、いくつかの並行性の問題から安全であると誤って誤っていることがよくあります。

ロック（例：Djangoのselect_for_update()）や楽観的な並行性など、プレーンなトランザクションに加えて使用できるその他のツールを理解し、検討することも重要です。