-
Notifications
You must be signed in to change notification settings - Fork 58
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
Managing the same lock with different handlers #451
Comments
@brainix, you assigned an uuid specific to objects and identify an lock by its uuid in redis scripts: Line 305 in 47da5f8
This is weird. According to https://redis.io/topics/distlock:
But, I think, different
|
Same issue here - you'd expect a distributed lock - to be distributed; if you can't check if a lock is locked from a different resource then there isn't much use. |
Same issue here - There is no sense to release the lock with the same Redlock instance from acquiring. In my opinion, the key and master should be sufficient to release. |
Can confirm, there is something wrong with the locks, deadlocking for no reason
|
That is certainly a problem, and it took me a while to understand why this is not working (the UUID creates uniqueness). I was hoping to use this to create some kind of a semaphore, now I wonder if I should implement it myself or just wait for the resource to be released. |
I don't know if we have the same issue.
The same key is used between services. It normally works fine (probably when they are not using it at the same time) and then some times we get I've added some logs to see if what was running inside and it seems it finishes running. Then would it mean another lock acquired it and released it when this one was supposed to have it? I'll be checking more in depth to add more info, but if some one has a hint of what could be happening or what I could look for would be greatly appreciated. Update: Update 2:
|
It's weird, I got same error by below code. with Redlock(
key=f"{func.__module__}:{func.__name__}",
masters={get_redis_conn()},
context_manager_blocking=False
):
pass # do something here Error Info:
|
How about larger auto_release_time |
Describe the bug
Sometimes I need to acquire and release the same lock with different objects. I am constricted by a legacy design to do it this way, because acquiring and releasing the lock will be in separate processes. However, if I open a second handle to the same lock key, I can't release the lock from there.
To Reproduce
Expected behavior
Environment (please complete the following information):
Additional context
Currently I just ignore the Exception, as most locks will expire in time anyway. However, that is probably bad practice.
The text was updated successfully, but these errors were encountered: