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

_read_lock sometimes has no responses. #24

Merged
merged 2 commits into from Aug 1, 2013
Merged

Conversation

dreid
Copy link
Contributor

@dreid dreid commented Aug 1, 2013

This is possibly because between the write and the read the TTL may have expired, it could also be a general consistency issue.

This change causes _verify_lock to raise a NoLockClaimsError and for acquire to retry on said error.

_verify_lock first releases it's claim because if this is caused by a consistency problem we can't guarantee that the row won't then exist on the later read. It should be safe to always DELETE even if no valid claim exists.

@rockstar
Copy link
Contributor

rockstar commented Aug 1, 2013

+1 from me

dreid added a commit that referenced this pull request Aug 1, 2013
_read_lock sometimes has no responses.
@dreid dreid merged commit 08230cb into master Aug 1, 2013
@dreid dreid deleted the auto-463-lock-ttl-expires branch August 1, 2013 22:53
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.

None yet

2 participants