この投稿から。明らかな問題の 1 つは、スケーラビリティ/パフォーマンスです。トランザクションの使用が引き起こす他の問題は何ですか?
問題には、長時間実行されるトランザクションと短時間実行されるトランザクションの 2 つのセットがあると言えますか? はいの場合、それらをどのように定義しますか?
編集: デッドロックは別の問題ですが、アプリケーション ドメインによっては、データの不整合がさらに悪化する可能性があります。トランザクションに値するドメイン (標準的な例を使用する銀行業) を想定すると、デッドロックの可能性は、トランザクションの使用に関する問題ではなく、データの一貫性を確保するために支払うコストのようなものですか? それとも同意しませんか? もしそうなら、デッドロックのないデータの一貫性を確保するために、他にどのようなソリューションを使用しますか?
これは、データベース内のトランザクション実装に大きく依存し、使用するトランザクション分離レベルにも依存する場合があります。ここでは「反復可能な読み取り」以上を想定しています。トランザクションを長時間 (何も変更していないものでも) 開いたままにしておくと、データベースは頻繁に変更されるテーブルの削除または更新された行を保持することになります (それらを読み取ることにした場合に備えて)。
また、トランザクションのロールバックは非常にコストがかかる可能性があります。MySQL の InnoDB エンジンでは、大きなトランザクションをロールバックすると、コミットするよりもはるかに長い時間がかかることがあります (ロールバックに 30 分かかることがわかっています)。
もう 1 つの問題は、データベースの接続状態に関するものです。分散型のフォールト トレラント アプリケーションでは、データベース接続がどのような状態にあるかを実際に知ることはできません。ステートフルなデータベース接続は、いつでも失敗する可能性があるため、簡単に維持できません (アプリケーションは、それがどのような状態だったかを記憶する必要があります)。途中でやめてやり直し）。ステートレスなものは再接続するだけで、(ほとんどの場合) 状態を壊すことなく (アトミック) コマンドを再発行できます。
明示的なトランザクションを使用しなくても、デッドロックが発生する可能性があります。まず、ほとんどのリレーショナル データベースは、実行する各ステートメントに暗黙的なトランザクションを適用します。
デッドロックは基本的に、複数のロックを取得することによって発生します。複数のロックを取得するアクティビティは、最初のアクティビティと同じロックを少なくとも 2 つ取得する他のアクティビティとデッドロックする可能性があります。データベース トランザクションでは、取得したロックの一部が、実際にはトランザクションの最後まで、他の方法で保持されるよりも長く保持される場合があります。ロックが長く保持されるほど、デッドロックが発生する可能性が高くなります。これが、実行時間の長いトランザクションが、実行時間の短いトランザクションよりもデッドロックの可能性が高い理由です。
トランザクションの問題の 1 つは、DB でデッドロックが発生する可能性があることです (可能性は低いですが、可能性はあります)。これらの興味深い/イライラする問題をデバッグするには、データベースの仕組み、ロック、トランザクションなどを理解する必要があります。
-アダム
主な問題は設計レベルにあると思います。アプリケーション内のどのレベルでトランザクションを利用するか。
たとえば、次のことができます。
同じアプリケーションでこれらのレベルを複数使用すると、多くの場合、パフォーマンスやデータの整合性の問題が発生するようです。