NES (.NET Event Sourcing) transactions fail?

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.

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/

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.