Use more generic (and SQL Server compatible) locking in reserve #38

merged 1 commit into from Mar 1, 2013


None yet

4 participants


The code in reserve seemed unnecessarily DB specific and fragile, replaced it to use AR lock method instead. The motivation was SQL server compatiblity


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.

@sferik sferik merged commit a297748 into collectiveidea:master Mar 1, 2013

1 check passed

Details default The Travis build passed

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
@albus522 albus522 referenced this pull request Mar 28, 2013

Fix job locking #46

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment