Guaranteeing transactions with multiple Listeners

Question

Recently my team has inherited a code-base with an interesting problem.

The system keeps historical records by having multiple listeners on the same event. These listeners execute serially, so if we have listener A, B, and C, B would wait for A to finish first before C and so-on.

Each listener updates a separate table.

However, if the system goes down while we're attempting to write B, then the tables in A, B, and C will come out of sync.

Is there a good solution for getting a transactional write for these listeners without coupling the listeners together?

Answer 1

You pass the same transaction to every participant. Then they use the same transaction and still don't know each other. Obviously, now they (or at least their result) is coupled, but having either all or none of them succeed is the whole point, right?

Passing in the transaction is not foolproof (they simply might not use it if they are negligent or mean harm) but it's the best option you got, there is no way to force a piece of code to use a transaction if they would be able to connect on their own as it seems to be the way it works today.

If A, B and C are on different systems, you can use distributed transactions for that scenario.

Answer 2

It's not as hard as you think.

What you can do is number your transactions and check if those numbers are in sync. If your system goes down and up again and it sees a transaction has happened in A but you can't find a corresponding number in B or C, remove every transaction with that number as if it never happened.