zlacker

if you care to elaborate, i'm curious -- what alternative(s) would you recommend instead of one transaction per message, and why?

>>shoo+(OP)
The article's approach is to have a column that stores if he job has been claimed and then handles dead jobs by just having a timeout.

>>shoo+(OP)
What if you want to store an error message+status with the job if it fails? It means you have to commit something no? What if you want to mark the message as being worked on and what process locked it and when they did for some kind of job queue monitoring stats?

The times I have done this, I end up with a workflow where the "select for update ... skipped lock" is used only to initially mark the job as "taken" so that other processes do not start working on it. That update is committed in one transaction and then the "work" is done in second transaction.