added lock option for enqueue and retry methods (#7) #22
Conversation
|
The last time this feature was discussed it did not have a lot of support. |
|
Yes, I see. But I think |
|
Well, personally i have no need for this feature, so maybe i should start with a 👎 vote. Especially since i've not seen anything similar in other job queues yet, so this is not a proven approach. |
|
What is the performance impact when this feature is not used? |
|
I have already described example of usage in #7 (comment) For example, you have two servers with the same configuration (mojo app + minion worker) and you need run periodically jobs (enqueued via cron). So you must solve the problem with duplication of same tasks. Without Of course, this is only my opinion. |
| $options->{delay} // 0, $options->{priority} // 0, | ||
| $options->{queue} // 'default', $task | ||
| )->hash->{id}; | ||
| my $result = eval { |
There was a problem hiding this comment.
Wouldn't an ON CONFLICT DO NOTHING work much better than eval?
There was a problem hiding this comment.
Yes, here it would be appropriate. But it requires a postgres 9.5.
There was a problem hiding this comment.
Minion will soon require PostgreSQL 9.5 anyway for SKIP LOCKED.
There was a problem hiding this comment.
Ok, I'll fix this when config for travis will be improved.
|
Regarding what features to accept, as long as we don't have more users willing to vote, i think features will be limited to what i need and/or what most other job queues support. |
|
Also there are recurring/periodic jobs (https://github.com/mperham/sidekiq/wiki/Ent-Periodic-Jobs) that cover my needs with lock option. I think it's more general case, which can enjoy more popularity. |
|
Yes, periodic jobs does look like a pretty nice feature, but also really hard to get right, makes sense Sidekiq only has it in the commercial version. |
|
But back to what this pull request is about, unique jobs. Why does the |
|
Unique jobs in sidekiq also have a time period attached. https://github.com/mperham/sidekiq/wiki/Ent-Unique-Jobs |
|
Hmm, I thought that the user should care about what jobs need not be repeated specifying a unique key for them. How The decision of sidekiq "1 job for a 1 task in a certain period" also looks like a working. |
|
Looks like we can't reach consensus on what the right way for implementing unique jobs would be. The question about performance cost is also still unanswered. And it appears that what everyone asking for unique jobs really wants is periodic jobs, perhaps we should consider that first. |
|
I think a feature like this is still very likely to be added in the future, but we have to look at it from all angles first, the real goal is scheduled/periodic jobs. |
|
Just so i don't forget to mention it in future discussions, the way the |
No description provided.