-
Notifications
You must be signed in to change notification settings - Fork 32
Transactions
To understand transactions with NES you'll need to know a bit about message idempotency.
A message is idempotent if the service operation that processes it yields the same result regardless of the number of times the message is received.
Please take a look at the following blogs, they explain message idempotency and 2PC much better than I can:
- http://bill-poole.blogspot.com/2008/06/idempotent-messages.html
- http://blog.jonathanoliver.com/2010/04/extending-nservicebus-avoiding-two-phase-commits
- http://blog.jonathanoliver.com/2011/04/how-i-avoid-two-phase-commit
The EventStore by default suppresses any ambient transaction created by NServiceBus before committing changes to the database. However if you are using a queue and a database that support distributed transactions (MSMQ, SQL Server, Raven etc) then you can change the EventStore's TransactionScopeOption to Required. This will ensure that the EventStore enlists in the ambient transaction, of which will become distributed using the MSDTC, and the message queue and database will be kept in-sync.
The EventStore uses a Guid to uniquely identify a commit against the database to prevent the same stream of events from being persisted more than once. If you're not using distributed transactions then a Guid should be included in all messages that are to going to be processed and result in the persistence of events - NES will by convention look for a property named 'Id' on any message being processed and will use its value as the CommitId when saving to the database.