skip to Main Content

I am building a feature the logs all changes made to entities inside an EF Core transaction.

I get the changes from change tracker and send it to service bus queue.

But I have a problem, if I send the changes before the transaction commits, the transaction may fail, but the changes have already been sent to the queue.

Another approach is to send the changes after the transaction is confirmed, but the send operation may go wrong and I will lose tracking.

I’m thinking of some solutions, I don’t even know how to search this, but I’m sure this problem is already known by some name in the community and has a specific technique to solve it

2

Answers


  1. Azure Service Bus and EF code cannot share a transaction. You’re right about your dilemma at hand. What I would suggest is an outbox approach. Along with the entity changes, you also store a record that curves as an instruction to dispatch a message. Give the record in the DB along with the entities. The same transaction would span all the items saved to the database. In case of a failure, nothing would get stored. You could have a separate processor responsible for dispatching ASB messages based on the outbox records. Think of it as a to-do list processor. And if it fails, it will restart and resend the message. You could have duplicate acknowledgement messages, but there are ways to handle duplicates, either using ASB native message de-duplication or custom idempotency on the receiving side.

    With this approach, a message will be dispatched only when entity changes are successful, guaranteed to be sent out by the outbox record. Until the outbox record is marked as completed.

    Here are a few links on the topic of the Outbox pattern:

    1. https://microservices.io/patterns/data/transactional-outbox.html
    2. https://medium.com/design-microservices-architecture-with-patterns/outbox-pattern-for-microservices-architectures-1b8648dfaa27
    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search