Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't use get_lock in the default implementation. #5

Closed
wants to merge 1 commit into from

Conversation

vickenty
Copy link
Collaborator

Fixes #4

get_lock() changes behaviour in MySQL 5.7, which causes in turn causes
workers to lock more rows than necessary.

This patch changes the behavior of Data::Consumer::MySQL2 to claim rows
by doing SELECT followed by UPDATE, instead of two SELECTs (second
select was necessary to validate result of GET_LOCK() since it wasn't
atomic, and was a major change from Data::Consumer::MySQL).

SELECT followed by UPDATE allows two claim strategies to be implemented,
both relying on implicit database locks: atomic CAS (used by default)
and SELECT FOR UPDATE.

get_lock() changes behaviour in MySQL 5.7, which causes in turn causes
workers to lock more rows than necessary.

This patch changes the behavior of Data::Consumer::MySQL2 to claim rows
by doing SELECT followed by UPDATE, instead of two SELECTs (second
select was necessary to validate result of GET_LOCK() since it wasn't
atomic, and was a major change from Data::Consumer::MySQL).

SELECT followed by UPDATE allows two claim strategies to be implemented,
both relying on implicit database locks: atomic CAS (used by default)
and SELECT FOR UPDATE.
davydovmax added a commit to davydovmax/Data-Consumer that referenced this pull request Sep 19, 2017
…nored

Without a fix, if we encounter this scenario, we will get an infinite loop in acquire():
1. start consuming
2. explicitly ignore() any item
3. continue consuming
4. wait till reset() is called (queue is exhausted or consume() called again)
4. try consume more items
5. acquire() receives already ignored item
    6. item is ignored but $self->{last_id} is not updated
    7. we skip item and loop back to demerphq#5, where process same item again

Fix just updates $self->{last_id} when we skip an ignored item. This
logic is similar to original logic in Data::Consumer::MySQL.
@demerphq
Copy link
Owner

demerphq commented Nov 1, 2017

What do you think of https://github.com/demerphq/Data-Consumer/tree/remove-get-lock-2

It looks to me we need to take some defensive measures before we can merge this.

See #7

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

MySQL get_lock is no longer limited to one lock per session
2 participants