服务总线1.0的Windows服务器交易/错误处理

问题描述：

我敢肯定，我不是第一个说这件事，但严重缺乏有关服务总线1.0的Windows Server服务器的更好的点的文档...我希望一些业内人士MS可以帮助清除一些事情......服务总线1.0的Windows服务器交易/错误处理

不要使用队列/主题服务于隐，环境事务中运行？例如考虑下面的代码片段：
```
[ServiceBehavior] 
public class MySbService : IDoWork 
{ 
    [OperationBehavior] 
    void DoSomeWork(WorkRequest request) 
    { 
     DoDatabaseWork(); 

     DoMoreDatabaseWork(); 
    } 
} 
```
在上面的示例，而无需创建一个明确TransactionScope，将DoDatabaseWork()承诺如果DoMoreDatabaseWork()抛出一个异常？换句话说，排队操作是否在由MSDTC跟踪的环境事务下运行？
服务总线1.0队列自动重试，如果引发异常（就像MSMQ一样）？我问，因为我没有遇到指定重试行为的netMessagingBinding的任何.config设置。另外，当使用Service Bus Explorer创建队列时，我看到的最接近的是MaxDeliveryAttempt。来自MSMQ背景，我习惯于看到异常消息出现在重试/毒性队列中。在Service Bus 1.0世界中是否有与此相似的东西？

预先感谢您

UPDATE：

请参考下面我的回答更多的细节。我正在修改此问题以询问以下内容：

是否有可能使用契约优先，IIS托管的WCF与Service Bus 1.0'覆盖'将客户端发送到事务中的服务总线？如果是这样，怎么样？另外，使用什么机制？

答

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

对于Transactional操作，我不相信有一个“环境”的交易。我已经通过在数据库操作之后抛出一个异常来证明这一点，并且确信无论如何都会提交数据。我想知道，如果有申报事务范围的首选方法，即：
```
[OperationBehavior(TransactionScopeRequired = true)] 
public void MyServiceOperation(){ ... } 

//or using the TransactionScope 

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

重试功能，它看起来像你需要启用ReceiveContext，following this blog：

[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("..."); 
    } 
}

UPDATE：

挖得更深一些之后，我发现OperationContext`ç如果您使用普通香草，合同优先，IIS托管的WCF和Service Bus 1，ompletion并不是一个真正的选择。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！

据我所知，工作流服务和直接处理中介消息为您提供一些开箱即用的重试功能。但是，如果你是通过AppFabric通过IIS托管你的工作流服务的IIS，那么微软就会想出如何让交易包括发送到服务总线。（如果有人知道该机制是什么，请让我知道！）

答

＃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

谢谢你的回答。我确实更新了我的问题，询问开箱即用的内部机制可以事务性地处理客户端发送部分，因此我不会将其标记为答案。我研究了瞬态故障处理库，但是当OperationContext和BrokeredMessages被利用时，它大部分似乎是相关的，但是我明确地问了如何做到这一点。 – Didaxis 2013-04-25 19:01:17

服务总线1.0的Windows服务器交易/错误处理

相关推荐