CODEWITHSUNDEEP
c#algorithmasp.net-core.net-coretransactions
vsir
vsir

Reputation: 369

Ensuring atomicity between different .NET Core services

Since .NET Core does not support distributed transactions yet (https://github.com/dotnet/runtime/issues/715), I am trying to think of a way to ensure atomicity in one of the flows in my application.

The flow goes as follows:

What can go wrong here is that the process of A can e.g. be killed before storing the response in its database which would result in data being stored in B but not in A and this is something I want to avoid.

I cannot think of a very simple way of solving this issue. My best bet is probably introducing some additional cleanup logic in 'A' but I was wondering if there would be a simpler and smarter way to do this.

Upvotes: 0

Views: 207

Answers (1)

David Browne - Microsoft
David Browne - Microsoft

Reputation: 89406

You could use asynchronous processes with guaranteed delivery. IE A sends a guaranteed delivery request to B. B performs some operation and sends a guaranteed delivery response to A. This can be implemented with a messaging system (Azure Service Bus, RabbitMQ, etc), or by simply using each app's local database as an outbound queue for messages. So A doesn't directly send a request to B, a saves the request in its database and some background process eventually calls B. Then B does the same with the response.

You can also do this with "coordinated" database transactions. IE A starts a transaction T1 and writes to B's database. A starts a second transaction T2 and writes the response to A's database. If both writes succeed, A logs the response from B, commits T1 and then T2 in rapid succession. If T1 commits and T2 fails to, A logs the failure and operational intervention is required.

This is essentially how Distributed Transactions work anyway. Even with a "real" distributed transaction there's some small possibility that one of the participants can fail to commit.

Upvotes: 2

Related Questions