zlacker

[return to "River: A fast, robust job queue for Go and Postgres"]
1. hipade+Xb[view] [source] 2023-11-20 16:56:41
>>bo0tzz+(OP)
What a strange design. If a job is dependent on an extant transaction then perhaps the job should run in the same code that initiated the transaction instead of a outside job queue?

Also you pass the data a job needs to run as part of the job payload. Then you don't have the "data doesn't exist" issue.

◧◩
2. maherb+Gu[view] [source] 2023-11-20 17:58:22
>>hipade+Xb
I think you may be misunderstanding the design here. The transaction for initiating the job is only for queuing. The dequeue and execution of the job happens in a separate process.

The example on the home page makes this clear where a user is created and a job is created at the same time. This ensures that the job is queued up with the user creation. If any parts of that initial transaction fails, then the job queuing doesn't actually happen.

[go to top]