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

Merged
merged 1 commit into from Mar 1, 2013

Projects

None yet

4 participants

@superchris

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

@sferik

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.

@superchris
@sferik

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
@jnimety

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

@aripollak

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
Merged

Fix job locking #46

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