在transactionScope中多次发布失败

我模拟了不同子系统之间的集成架构。所有来自子系统的通知都使用原始Publish发送到订阅的子系统。这些通知在Handler方法内的for循环中发送，因此它们全都在相同的TransactionScope中。我做了一个简单的例子来解释这一点：客户端发送消息到服务器，该服务器使用原始Publish发送可变数量的消息。这是服务器处理器：在transactionScope中多次发布失败

public void Handle(MyMessage message) 
    { 

     for (int i = 0; i < message.numberOfNotifications; i++) 
     { 
      Bus.Publish<NotificationMessage>(m => 
      { 
       m.myPersonalCount= i; 
      } 
      ); 
     } 
    }

我正在寻找，我想不通的是，当我设置i 30或更少一切正常。从31以上我收到此错误信息：

could not execute query 
[ SELECT this_.SubscriberEndpoint as y0_ FROM "Subscription" this_ WHERE this_.MessageType in (?) ]

而且看在内部异常，我得到Unable to enlist in a distributed transaction。

我试着使用原始Send，但一切都是（尝试10k消息），所以这是一个问题仅针对Publish指令。

我使用的数据库管理系统和Oracle 11g客户端的Oracle 10g。

如果端点不是事务性的，我没有任何问题，所以这个问题似乎只与TransactionScope的关心。

任何帮助表示赞赏，谢谢

来源

2012-11-16 Riccardo

您使用的是什么版本的NServiceBus？ –

@ChrisBednarski我用versione 2.0.1329.2，我知道这是一个很老的版本.. – Riccardo

我建议移动到NSB的新版本 - 类似在这里回答http://stackoverflow.com/a/12478656/136720 –

我不是任何想象力的Oracle专家。我可能甚至不会有资格成为新手。

但是，我知道，NServiceBus查询认购存储为每一个发布，万一有变化订阅出版之间。

难道Oracle客户端具有某种限制在分布式事务处理多少查询可以争取？也许是为了防止N + 1类型的性能问题？

这就是说，它似乎很奇怪，你将要发布30多个同类型的事件的。我想知道你的业务用例是什么。通常情况下，事件会宣布发生了不可挽回的事情。为什么会发生30件事？

如果业务案例稳定，那么实现自己的订阅存储引擎可能是一个好主意，该引擎使用一些有限的缓存（甚至是5秒钟），以便在每次发布时不返回查询数据库。

来源

2012-11-16 17:50:33

我有单个事件可以设置多达20k通知消息。我做了这件事，因为我的系统预计可扩展性强，并且发送所有这些小信息，而不是一个包含大量数据的小信息，在我看来，它更适合我的性能限制。你有什么想法？但是，如果端点不是事务性的，我没有任何问题，所以问题似乎在TransactionScope上下文中。 – Riccardo

在transactionScope中多次发布失败

回答

相关问题