The code in reserve seemed unnecessarily DB specific and fragile, replaced it to use AR lock method instead. The motivation was SQL server compatiblity
this works with SQLServer and appears to be generally less database s…
…pecific and fragile
What’s the reason not to use the PostgreSQL-optimized code for the PostgreSQL case? I’d be okay with your implementation being the else case. This code was added in #29 as a PostgreSQL-specific performance optimization. I’d hate to rip it out and have a degradation of performance for our PostgreSQL users. However, I would also like to support Microsoft SQL Server. I believe both of these goals can be achieved with a simple conditional statement.
Okay, I'm convinced.
Thanks for the patch.
I'm still investigating but since I rolled from 0.4.2 to 0.4.3 in production some of my jobs are running multiple times. Email headers show that duplicate emails are originating from different workers/servers. Seems like locking is broken. I'm using mysql. /cc #40
I think this still contains a race condition - two workers can get to the with_lock at the same time with the same job, and they'll both update the same job & return it in sequence, so the job would get processed twice. Since with_lock reloads the job with the lock, I think this can be fixed by just putting this after the with_lock:
return if job.locked_at || job.locked_by