mookid8000
commented
4 years ago Is this implemented in a different way?
Rebus generally does not assume in any way that things happen atomically across persistence technologies, so even if you use the same technology (i.e. SQL Server) as both transport and attachment storage, then Rebus will not try to enlist operations of those things into the same transaction.
This way, Rebus will behave in a very consistent fashion, even if you swapped the transport out with RabbitMQ and started using MongoDB or the file system as your attachment storage.
Does having two DB connections open, one for transport, one for data bus lead to potential data inconsistencies?
Well, it does. You do risk that you create an attachment, and then you fail to send a message containing that attachment's ID (which is effectively your "handle" of the attachment) somehow.
This way, you can have "dangling attachments" sitting around in your attachment storage. Rebus 6 will provide a simple way of querying the attachment storage, making it possible to write a simple cleanup task, which could periodically delete attachments that was not read within e.g. a week or so.
I hope that answers your questions 😄
matt-psaltis
I'm trying out the Sql server data bus and started hitting SqlExceptions such as "The transaction operation cannot be performed because there are pending requests working on this transaction." from our message handlers.
This is because we configured the Data bus to use the same DB connection that the transport is using. I can see within SqlServerDataBusStorage that it completes the connection in several of the method calls which seems to indicate that this won't work the way we expect.
Main reasoning for this is so that we get atomic commit for messages and attachments alike.
Is this implemented in a different way? Does having two DB connections open, one for transport, one for data bus lead to potential data inconsistencies?