2

それを言うのは私が最初ではないことは確かですが、Windows Server 用の Service Bus 1.0 の細かい点に関するドキュメントが深刻に不足しています。いくつかのこと...

  1. キュー/トピックを利用するサービスは、暗黙的なアンビエント トランザクションで実行されますか? たとえば、次のコード スニペットを考えてみましょう。

    [ServiceBehavior]
public class MySbService : IDoWork
{
    [OperationBehavior]
    void DoSomeWork(WorkRequest request)
    {
        DoDatabaseWork();

        DoMoreDatabaseWork();
    }
}

    上記のサンプルでは、​​明示的な を作成せずに、例外をスローするTransactionScopeとDoDatabaseWork()コミットされますか? DoMoreDatabaseWork()つまり、キューに入れられた操作は、MSDTC によって追跡されるアンビエント トランザクションの下で実行されますか?

  2. Service Bus 1.0 キューは、例外がスローされた場合 (MSMQ のように) 自動的に再試行しますか? 再試行動作を指定.configする の設定に出くわしていないため、質問します。また、私が見る最も近いものをnetMessagingBinding使用してキューを作成するときは. 私は MSMQ のバックグラウンドを持っているため、再試行/ポイズン キューに例外メッセージが表示されるのに慣れています。Service Bus 1.0 の世界でこれと同義の何かがありますか?Service Bus ExplorerMaxDeliveryAttempt

前もって感謝します

アップデート：

詳細については、以下の私の回答を参照してください。この質問を次のように変更しています。

コントラクト優先の IIS でホストされる WCF を Service Bus 1.0 で使用して、トランザクションでサービス バスに送信するクライアントを「カバー」することは可能ですか? もしそうなら、どのように？また、どのような仕組みが使われているのでしょうか?

4

2 に答える 2

2

私は両方の質問に対する答えを見つけたと信じています...

  1. 運用に関してTransactionalは、「周囲の」トランザクションがあるとは思いません。データベース操作の後に例外をスローするだけでこれを証明しましたが、確かに、とにかくデータはコミットされます。トランザクション スコープを宣言するための推奨される方法があるかどうかを知りたいです。

    [OperationBehavior(TransactionScopeRequired = true)]
public void MyServiceOperation(){ ... }

//or using the TransactionScope

public void MyServiceOperation()
{
    using(var transScope = new TransactionScope(...)){ ... }
}

  2. 再試行機能についてはReceiveContext、次のブログを有効にする必要があるようです:

    [ServiceContract]
public interface IMyService
{
    [OperationContract(IsOneWay=true)]
    [ReceiveContextEnabled(ManualControl = true)]
    void MyServiceOperation();

// and in the service implementation:

[OperationBehavior]
public void MyServiceOperation()
{
    var incomingProperties = OperationContext.Current.IncomingMessageProperties;
    var property = incomingProperties[BrokeredMessageProperty.Name] as BrokeredMessageProperty;

    //Complete the Message

    ReceiveContext receiveContext;
    if (ReceiveContext.TryGet(incomingProperties, out receiveContext))
    {
        //Do Something                

        receiveContext.Complete(TimeSpan.FromSeconds(10.0d));
    }

    else
    {
        throw new InvalidOperationException("...");
    }
}

アップデート：

もう少し深く掘り下げた後、Service Bus 1.0 で単純なバニラ、コントラクト ファースト、IIS でホストされる WCF を使用している場合、OperationContext` の補完は実際にはオプションではないことがわかりました (理由はわかりませんが、誰かがこれに光を当ててくれることを願っています）

私が見つけたのは、トランザクション動作の唯一の適切なオプションは次のとおりです。

[OperationBehavior]
public void MyServiceOperation()
{
    using(var transScope = new TransactionScope(...))
    {
        DbWork();
        transScope.Complete();
    }

    Client.SendToServiceBus(); // <-- Cannot be part of transaction, otherwise
                               //     exceptions will be thrown!
}

MSMQ などとは異なり、このパターンでは、サービス バスへのメッセージの送信が失敗した場合に操作全体をロールバックできないという問題が残ります。（もちろん、誰かがもっとよく知っている場合を除きます...）

これはまた、独自の再試行ロジックと、前のステップがコミットされたことを次のステップで検証する何らかのメカニズムをロールバックする必要があることも意味します。うん！

私の理解では、Workflow Services と仲介されたメッセージを直接処理することで、すぐに使用できる再試行機能が提供されます。しかし、AppFabric を介して IIS でワークフロー サービスを IIS でホストしている場合、Microsoft はどういうわけか、サービス バスへの送信をカバーするトランザクションを取得する方法を見つけ出しました。（その仕組みを知っている人がいたら教えてください！）

于 2013-03-20T16:01:36.540 に答える
0

＃2については、一時的な障害処理フレームワークを介して再試行できます

http://windowsazurecat.com/2011/02/transient-fault-handling-framework/

Service Bus に関連する使用方法については、このドキュメントを参照してください。

http://social.technet.microsoft.com/wiki/contents/articles/best-practices-for-leveraging-windows-azure-service-bus-brokered-messaging.aspx?Sort=MostRecent&PageIndex=1

于 2013-04-23T18:10:37.437 に答える