TransactionScope が一部のマシンでは MSDTC にエスカレートされ、他のマシンではエスカレートされないのはなぜですか?

トランザクションスコープ: マシン間での MSDTC エスカレーションの不一致

私たちのプロジェクトは信頼性の高いデータ アクセスのために TransactionScope を使用していますが、一貫性のない動作が発生しました。一部の開発者は MSDTC なしでシームレスに作業しますが、他の開発者は「[SERVER] の MSDTC は利用できません」というエラーを受け取ります。 この調査では、TransactionScope が一部のマシンでは MSDTC にエスカレーションされ、他のマシンではエスカレーションされない理由を調査します。

TransactionScope は、クライアント マシン上で MSDTC を回避するのが理想的です。ただし、いくつかのシナリオでは DTC エスカレーションがトリガーされる可能性があります:

• 単一フェーズ通知が欠落している複数の耐久性のあるリソース (除外)。
• 同じデータベースへの複数の接続 (コードレビューによって除外されました)。
• クロスアプリケーション ドメインまたはプロセス トランザクション マーシャリング (除外)。

ただし、コードにはネストされた接続の開始が含まれており、単一のオープン接続の主張と矛盾しています。このネストされた接続は、影響を受けるマシンでのエスカレーションの問題の可能性が高いです。 SQL Server のバージョンは重要な役割を果たします。 SQL Server 2008 ではトランザクション処理が改善され、エスカレーションなしで TransactionScope 内で複数の接続 (異なる時間に開かれる) が可能になりました。 ただし、SQL Server 2005 にはこの機能がないため、2 番目の接続で DTC にエスカレーションされます。

重要なのは、エスカレーションの問題が発生していない開発者は SQL Server 2008 を使用しているのに対し、エラーが発生している開発者は SQL Server 2005 を使用していることです。これは、SQL Server のバージョンと MSDTC エスカレーションの間に相関関係があると考えられることを裏付けています。

SQL Server 2005 の場合、TransactionScope が正しく機能するには、単一の長期間有効なグローバル接続が必要です。これはベスト プラクティス (必要な場合にのみ接続を開き、すぐに閉じる) と矛盾します。 SQL Server 2005 での TransactionScope の使用は、永続的な接続のパフォーマンス オーバーヘッドが許容できる場合を除き、最適ではない可能性があります。

以上がTransactionScope が一部のマシンでは MSDTC にエスカレートされ、他のマシンではエスカレートされないのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。