Re:Practical Guide to SQL Transaction Isolation
by stickfigure on Tuesday August 08, 2017 @02:59AM
(#14955170)
A lock still doesn't give you a transaction across two systems that aren't transactionally connected. If you're specifically worried about retries you can create a "task" (row in a table) in the transaction and have a consumer read tasks and propagate the message.
A lock is seductive because in the happy path it looks like you have a distributed transaction. In practice making reliable calls across distributed systems involves more complexity. The hard part is figuring out what to do when your remote call times out and you aren't sure if it succeeded; once you resolve that, you can usually work with any concurrency scenario.
A lock is seductive because in the happy path it looks like you have a distributed transaction. In practice making reliable calls across distributed systems involves more complexity. The hard part is figuring out what to do when your remote call times out and you aren't sure if it succeeded; once you resolve that, you can usually work with any concurrency scenario.