NES（.NET 事件源）事务失败？
我正在尝试 NES 0.3 (https://github.com/elliotritchie/NES)，但在理解发生的情况时遇到一些困难。我正在运行示例应用程序，其中我已将 EventStore 配置更改为 SQL Server，并在执行离开 SendMessageCommandHandler.Handle() 之前插入异常。
然后我启动处理程序和网站。我创建了一个新用户，进展顺利。我的 EventStore 表中注册了一个事件。然后我尝试发送消息。由于我的例外，这失败了。因此，由于总线的事务性质，没有调度 NServiceBus 事件。但在 EventStore 中，事件已注册并标记为 dispatched=1。
我缺少什么？当它没有被 NServiceBus 调度时，它肯定不应该被注册为已调度吗？错误队列中唯一的消息是“SendMessageCommand”。我的理解可能是错误的，所以我想在向作者报告这个问题之前我应该先在这里问一下。
I'm trying the NES 0.3 (https://github.com/elliotritchie/NES) but are having some trouble understanding what happens. I'm running the sample application where I have changed EventStore configuration to SQL server and inserted an exception just before execution leaves SendMessageCommandHandler.Handle().
Then I fire up the handler and the web site. I create a new user which goes well. One event registred in my EventStore table. Then I try to send a message. This fails due to my exception. So no NServiceBus event has been dispatched due to the transactional nature of the Bus. BUT in the EventStore the event is registered and marked with dispatched=1.
What am I missing? Surely it should not have been registered as dispatched when it has not been dispatched by NServiceBus? The only message in the error queue is the "SendMessageCommand". It is probably my understanding that is wrong so I thought I'd ask here before reporting this as an issue to the author.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
NES 0.3.0.1 版本 http://nuget.org/List/Packages/NES 将现在仅在所有处理程序成功运行后才提交任何更改。
不过，您仍然应该考虑自己管理消息幂等性。您可以通过多种方式执行此操作：
默认情况下，EventStore 在向数据库提交更改时会抑制任何环境事务。但是，如果您使用的是 SQL Server 或 Raven，您可以将 EventStore 的 TransactionScopeOption 更改为必需，这应确保事务将使用 MSDTC 进行分发，并且一切都会为您处理。
使用 2PC 的另一种方法是保留所有收到的消息的日志，并使用它来接受/拒绝对特定消息的处理。这种方法的一个例子可以在这里找到：http: //blog.jonathanoliver.com/2010/04/extending-nservicebus-avoiding-two-phase-commits/
The 0.3.0.1 version of NES http://nuget.org/List/Packages/NES will now only commit any changes after all your handlers have run successfully.
You should still consider managing the message idempotentcy yourself though. You can do this a couple of ways:
The EventStore by default suppresses any ambient transactions when committing changes to the database. However if you are using SQL Server or Raven you can change the EventStore's TransactionScopeOption to Required which should ensure the transaction will become distributed using the MSDTC and everything will be handled for you.
An alternative to using 2PC would be to be to keep a log of all received messages and use this to accept/reject processing of a particular message. An example of this approach can be found here: http://blog.jonathanoliver.com/2010/04/extending-nservicebus-avoiding-two-phase-commits/
在底层，NES 使用 EventStore 项目。根据设计，在调用 MarkAsDispatched() 之前，每次提交都不会被视为已调度。因此，我推测有些东西正在意外的位置调用该方法。
首先也是最重要的，您是否有一个正在运行的 EventStore 实例。确保您没有运行两个实例。除此之外，我建议单步执行处理程序以找出提交被标记为已分派的时间点。
Under the hood, NES uses the EventStore project. By design, each commit is not considered dispatched until MarkAsDispatched() is called. As a result, I would speculate that something is calling that method in an unexpected location.
First and foremost, do you have a single instance of the EventStore running. Ensure that you don't have two instances running. Beyond that, I would recommend stepping through the handler to find out at which point the commit is marked as dispatched.