We are implementing new systems which communicate to each other using Windows Service Bus. The Service Bus gives durability on the receiving of messages but we were worried about the durability of the send. The two error conditions we were worried about were:
- How can the sending application stay operational if the Service Bus is down?
- Our messages to the service bus are in conjunction to a database operation. Since the service bus doesn’t support enlisting in a distributed transaction, how do we make sure that a message gets sent if the database operation is successful and that a message does not send if the database operation isn’t successful.
The solution we came up with is to use HangFire to send the message to the Service Bus. If the service bus is down then HangFire will keep trying to send until successful. At the moment, HangFire seems to enlist in the ambient transaction so if the transaction is rolled back then the send queued in HangFire also rolls back.
Since coming up with this scheme, this seems like a really powerful and useful way to make things that don’t generally support transactions part of a transaction. However, this also doesn’t seem to be anything that is documented as a supported feature of HangFire. In fact, a literal reading of Reliability of background job processing would seem to indicate that the current behavior of HangFire is a bug and that HangFire’s TransactionScope should be set to not enlist in the ambient transaction. If that behavior were to be “fixed” then that would be a disaster for us. We would really like the current behavior to be adopted as official and supported, at least as a behavior of the default SQL storage engine.