服务总线1.0的Windows Server事务/错误处理(Service Bus 1.0 for

我敢肯定，我不是第一个说出来，但有一个严重缺乏文档的服务总线1.0的Windows Server细微之处有...我希望一些业内人士MS可以帮助清除一几件事情了......

不要使用队列/主题服务于隐，环境事务中运行？例如考虑下面的代码片段：
```
 [ServiceBehavior] public class MySbService : IDoWork { [OperationBehavior] void DoSomeWork(WorkRequest request) { DoDatabaseWork(); DoMoreDatabaseWork(); } } 
```
在上面的例子，而无需创建一个明确TransactionScope ，将DoDatabaseWork()如果犯下DoMoreDatabaseWork()抛出一个异常？换句话说，不通过MSDTC跟踪环境事务下运行排队操作？
如果抛出一个异常（如MSMQ不会）做服务总线1.0队列自动重试？我问，因为我还没有碰到过任何来.config设置为netMessagingBinding指定重试的行为。还创建使用队列时， Service Bus Explorer我看到最接近的是MaxDeliveryAttempt 。从MSMQ背景来了，我看惯了异常消息出现在重试/毒队列。是不是有什么synomomous这个在服务总线1.0的世界？

先感谢您

更新：

请参阅我的回答如下了解更多详情。我修改这个问题要问以下内容：

是否有可能使用契约优先，IIS托管，WCF与服务总线1.0〜“盖”客户端发送到服务总线的事务？如果是这样，怎么样？此外，所使用的机制是什么？

Answer 1:

我相信我已经找到了答案，我的两个问题...

对于Transactional操作，我不相信有一个“环境”的交易。我已经通过数据库操作后，简单地抛出一个异常证明了这一点，果然，数据无论如何承诺。我想知道，如果有申报的交易范围，即优选的方法：
```
 [OperationBehavior(TransactionScopeRequired = true)] public void MyServiceOperation(){ ... } //or using the TransactionScope public void MyServiceOperation() { using(var transScope = new TransactionScope(...)){ ... } } 
```

对于重试功能，它看起来像你需要启用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("..."); } }

更新：

挖一个更深一点之后，我发现OperationContext`完成是不是一个真正的选择，如果你使用的是普通的香草，合同第一，IIS托管，WCF与服务总线1.0（不知道为什么，但我米希望有人能提供一些线索这光）

我发现是有关交易行为的唯一理智的选择如下：

[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，不允许整个操作是回滚如果将消息发送到服务总线失败。（当然，除非有人在那里知道更好...）

这也意味着你不得不滚你自己的重试逻辑和可能的一些机制来验证在那之前的步骤提交的下一个步骤。 YUCK！

从我的理解，工作流服务，并直接与经纪公司的消息处理给你一些外的开箱重试功能。但如果你的IIS托管与IIS的工作流服务通过AppFabric的，后来不知怎的微软想出如何让交易支付发送到服务总线。（如果有人知道该机制是什么，请让我知道！）

Answer 2:

＃2，您可以打通瞬态故障处理框架试

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

通读此文档的使用相关的服务总线。

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

文章来源: Service Bus 1.0 for Windows Server Transaction/Error Handling