0

特定のエンドポイントに、SQL Azure データベースに対して作業を行うメッセージ ハンドラーがいくつかあります (現時点では、まだローカルの SQL 2012 インスタンスを使用しています)。X と Y という 2 つのイベントを発行するコマンド ハンドラーがあります。同じエンドポイントに、X へのサブスクライバーと Y へのサブスクライバーがあります。これらのサブスクライバーは両方とも、内部で同じデータ アクセス コンポーネントを使用しており、それを Z と呼びます。依存関係インジェクションは、共有ではなく、呼び出しごとに設定されます。

コンポーネント Z は、カーテンの下で Entity Framework 6 を使用しています。私が抱えている問題は、データベースを開くだけで SqlException がスローされ、MSDTC エスカレーションについて不平を言うことです。

ハンドラーを TransactionScope.Suppress で一時的にラップしたところ、エラーが停止しましたが、もっと基本的なものが欠けていると思います。

エンドポイントを非トランザクションに設定するのは簡単ですか? トランスポート メカニズムとして Azure Service Bus を使用するように構成したので、これはうまくいくと思っていたでしょう。これを行うと、メッセージ ハンドラ内で例外がスローされた場合でも、NServiceBus は再試行しますか? （SLRの制限まで-質問の一部ではありません。冪等性の問題も理解しています）。

4

2 に答える 2

0

@フィル、

まず、SQL Azure で MSDTC を使用しないでください。サポートされていません。この機能は提案されていますが、審査中です。DTC は Azure ではサポートされていません。または、次の提案を調べて、SqlTransaction アプローチを使用することもできます。

次に、使用しているトランスポートはデータ アクセスとは関係ありません。Azure Service Bus を使用しているため、ハンドラー コードの一部にはなりません。ハンドラーをトランザクション対応にすることは、アトミックな変更またはロールバックを強制することです。ハンドラーに関係なく、再試行します。課題は、ハンドラー/エンドポイントがトランザクション対応ではなく、ハンドラー内で DB への最初の書き込みが成功し、2 番目に失敗した場合、最初の書き込みが元に戻されないことです。トランスポートとしての Azure Service Bus は、その性質上トランザクションではありません (つまり、DTC ではありません)。

于 2014-10-08T02:32:30.147 に答える
0

どのバージョンの NServiceBus.Azure を使用していますか? 例外のスタック トレースはありますか? それはどこから来たのですか？

DTC への昇格を防ぐために、明示的に受信トランザクション スコープの範囲外に送信と発行をプッシュして、トランザクションが SQL に対してローカルになるようにします。

あなたの説明から、ハンドラーごとに (呼び出しコンテナー構成ごとに) 異なるデータ アクセス インスタンスを使用していて、同じメッセージに複数のハンドラーがあるように見えます。これらの両方が SQL への新しい接続を開くと、プロモーションも表示されます (同じサーバーであっても)。

それはそれでしょうか？2回目のオープンでスローすることは？

于 2014-10-08T08:10:41.073 に答える