データベースでトランザクションを使用する場合、どのような問題がありますか?

Question

から この郵便受け. 。明らかな問題の 1 つは、スケーラビリティとパフォーマンスです。トランザクションの使用によって引き起こされるその他の問題は何ですか?

2 つのセットの問題があり、1 つは長時間実行されるトランザクションに関するもので、もう 1 つは短期間実行されるトランザクションに関するものであると言えますか?「はい」の場合、それらをどのように定義しますか?

編集：デッドロックも別の問題ですが、アプリケーション ドメインによっては、データの不整合がさらに悪化する可能性があります。トランザクションに適したドメイン (標準的な例を使用すると銀行業務) を想定すると、デッドロックの可能性は、トランザクションの使用に関する問題というよりも、データの一貫性を確保するために支払うコストのようなものです。あるいは、あなたはそう思わないでしょうか。もしそうなら、デッドロックのないデータの一貫性を確保するために、他にどのようなソリューションを使用しますか?

Answer 1

これはデータベース内のトランザクション実装に大きく依存し、使用するトランザクション分離レベルにも依存する場合があります。ここでは「Repeatable Read」以上を想定しています。トランザクションを開いたまま (何も変更していないトランザクションであっても) 長期間保持すると、データベースは、頻繁に変更されるテーブルの削除または更新された行を (読み取りを行う場合に備えて) 保持することになり、そうでなければ破棄される可能性があります。

また、トランザクションのロールバックには非常にコストがかかる可能性があります。MySQL の InnoDB エンジンでは、大規模なトランザクションのロールバックにはコミットよりもはるかに長い時間がかかる可能性があることはわかっています (ロールバックには 30 分かかることが確認されています)。

もう 1 つの問題は、データベースの接続状態に関連するものです。分散型のフォールト トレラント アプリケーションでは、データベース接続がどのような状態にあるのかを実際に知ることはできません。ステートフル データベース接続はいつでも失敗する可能性があるため、簡単に維持することはできません (アプリケーションは実行中の内容を記憶し、再実行する必要があります)。ステートレスなものは、（ほとんどの場合）状態を壊すことなく、再接続するだけで（アトミックな）コマンドを再発行することができます。

Answer 2

明示的なトランザクションを使用しなくても、デッドロックが発生する可能性があります。まず、ほとんどのリレーショナル データベースは、実行する各ステートメントに暗黙的なトランザクションを適用します。

デッドロックは基本的に複数のロックの取得によって発生します。複数のロックの取得を伴うアクティビティは、最初のアクティビティと同じロックを少なくとも 2 つ取得する他のアクティビティとデッドロックする可能性があります。データベース トランザクションでは、取得されたロックの一部が、それ以外の場合よりも長く保持される場合があり、実際にはトランザクションの終了まで保持されます。ロックが保持される時間が長くなるほど、デッドロックが発生する可能性が高くなります。これが、実行時間が長いトランザクションの方が、短いトランザクションよりもデッドロックが発生する可能性が高い理由です。

Answer 3

トランザクションに関する問題の 1 つは、DB でデッドロックが発生する可能性があることです (可能性は低いですが、可能性はあります)。これらの興味深い問題やイライラする問題をデバッグするには、データベースの動作、ロック、トランザクションなどを理解する必要があります。

-アダム

Answer 4

大きな問題は設計レベルにあると思います。アプリケーション内のどのレベルでトランザクションを利用しますか。

たとえば、次のことができます。

• ストアド プロシージャ内でトランザクションを作成し、
• データ アクセス API (ADO.NET) を使用してトランザクションを制御する
• アプリケーションの上位で何らかの形式の暗黙的ロールバックを使用する
• (DTC / COM+ 経由) の分散トランザクション。

同じアプリケーションでこれらのレベルを複数使用すると、パフォーマンスやデータの整合性の問題が発生することがよくあります。