News for hackers. Stuff that matters.
Re:You Cannot Have Exactly-Once Delivery by hangonhn on Wednesday March 01, 2023 @04:30PM (#34988623)
So when does the receiver record the IDs? When it receives the message but before processing or after it's processed the message? If the former, then what if it goes down during processing? Then the other receivers will keep rejecting the message even though it's never processed. So now it's less than once. If the receiver records it after it's done processing, then it could go down after processing but before recording it in the DB. So now you have more than once.

Also, isn't the assumption here that you will have a reliable connection to a shared DB?

You can have engineered solutions that is pragmatically close to deliver exactly once but it's not "pure" -- there are still scenarios, however unlikely, that it will fail.

Re:You Cannot Have Exactly-Once Delivery by PaulKeeble on Wednesday March 01, 2023 @04:51PM (#34988849)
Even if you record both when it arrives and when its completed a power failure mid way will still leave everything in between in a partial state unless everything has XA transactional behaviour and as we know that scales quite poorly.
Re:You Cannot Have Exactly-Once Delivery by rowls66 on Wednesday March 01, 2023 @05:16PM (#34989109)
XA scales well enough for many workloads. I believe that too many developers discard solutions like XA because it "scales quite poorly" without doing serious analysis of how much scalability they are likely to need and whether XA scales well enough to support it. On the flip side I believe that too many developers underestimate the complexity of managing state and failure in distributed systems.
Re:You Cannot Have Exactly-Once Delivery by LgWoodenBadger on Wednesday March 01, 2023 @05:07PM (#34989016)
XA transactions have the exact same problems, it doesn't solve it either.