removing mysql optimization #75
Conversation
|
Changes Unknown when pulling 21d8f25 on michaelglass:no_deadlocks_on_5.6 into * on collectiveidea:master*. |
|
fixes #63 |
|
Could we get this or something like it merged in please? The optimization is fundamentally flawed as it causes deadlocks. If deadlocks were caught and retried this technique would be fine, but they are not. We're going to monkey patch for now, but it seems like this or some fix for it should be merged in. |
|
@aaronjensen I've left DJ for resque with resque-multi-job-forks. The migration wasn't that bad, and redis is so much faster for mysql for these types of tasks. If you wanna clean up my patch and fix tests, this is way more likely to get merged. I think a nice alternate to just cutting out optimizations is cutting out optimizations with a config or an env variable. But I'm ducking out because I'm not putting any more of my eggs into delayed job 😶 |
|
my company has moved to resque, so I'm closing this PR (because I'm not going to maintain it). Feel free to clone my repo and reopen from that if you wanna use this (ugggly) code. <3<3 -Mike |
@michaelglass How was the transition to resque? We're having deadlock issues as well and are now considering alternatives. |
|
@TafadzwaD if memory serves (this issue is from 10 years ago!) wasn't so bad. Also could try https://github.com/bensheldon/good_job |
these break mysql 5.6. The proposed patch is awful and I probably break tests, but it's worth starting this discussion in PR.