2 ms·
It's not strange at all to me. The job is "transactional" in the sense that it depends on the transaction, and should be triggered iff the transaction commits.
by teraflop 3y ago
It's not strange at all to me. The job is "transactional" in the sense that it depends on the transaction, and should be triggered iff the transaction commits. That doesn't mean it should run inside the transaction (especially since long-running transactions are terrible for performance).
Passing around the job's data separately means that now you're storing two copies, which means you're creating a point where things can get out of sync.
- deleted 3y ago[deleted]
- hipadev23 3y ago> should be triggered iff the transaction commits Agreed. Which is why the design doesn't make any sense. Because in the scenario presented they're starting a job during a transaction.
- j45 3y agoMaybe it’s not designed for that or all use cases and that can make sense. Personally, I need long running jobs.
- teraflop 3y agoI don't understand what you mean. The job is "created" as part of the transaction, so it only becomes visible (and hence eligible to be executed) when the transaction commits.
- Chris911 3y agoThe job is queued as part of the transaction. It is executed by a worker outside the scope of the transaction.
- eximius 3y agoThat part is somewhat poorly explained. That is a motivating example of why having your job queue system be separate from your system of record can be bad. e.g., 1. Application starts transaction 2. Application updates DB state (business details) 3. Application enqueues job in Redis 4. Redis jobworkers pick up job 5. Redis jobworkers error out 6. Application commits transaction This motivates placing the jobworker state in the same transaction whereas non-DB based job queues have issues like this.