4 ms·
For the sake of error handling on rollback, you're usually better delayed job enqueueing events to after commit hooks if you're concerned about failures resulti
by wpeterson 11y ago
For the sake of error handling on rollback, you're usually better delayed job enqueueing events to after commit hooks if you're concerned about failures resulting in a rollback.
- adamtj 11y agoDoing anything after committing misses the point. If you can do that, you don't need postgres. For example, suppose you mark an account closed, commit, and then enqueue an event to issue a refund from another system. It's possible that your process may crash or be killed at just the wrong time leaving you with a closed account but no refund. So what if you enqueue the event before you commit? In that case, you might crash before committing which will automatically rollback. Now you've done a refund on a non-closed account. Transactions make it trivial to guarantee that either both happen or neither do. There are other ways to get that guarantee, but they require more work and are more error prone.