3

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?

  • 4
    How can they be transactional without being coupled? The point of a transaction is to couple the writes together as an atomic unit! – Steve Feb 19 '18 at 2:32
  • Is there some non transactional coupling you're concerned with? Coupling comes in many forms. – candied_orange Feb 19 '18 at 3:06
4

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.

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.