context manager should wait till it get's the lock.

[msjaiswal]

Hello,

The way current implementation of 'with-statement' is done, if it fails to acquire the lock, it throws an exception. So, we still need to wrap this with-statement with our own retry logic. I believe that the retry logic should be built into the context manager. We should not be required to write any retry logic in addition to this. What are your views ?

# waste_time.py
# If you run multiple instances of this code, all the processes should wait for each other instead of throwing an exception.
import time
from redlock import RedLock
with RedLock("distributed_lock"):
  print("Critical Section started")
  for i in range(0,10):
    time.sleep(1)
    print("wasted %s seconds" % i)
  print("Critical Section finished")

[djenriquez]

Agreed, the protocol, states it should retry on failure here, given this issue is a few months old, do we see this being modified at all?

[judgeaxl]

It does retry, by default 3 times, but offers no API for retrying until an overall timeout. It's not really mentioned in the proposal either. The delay between retries is a random duration between 0 and 200ms, which could theoretically become close to fail in zero seconds if we're "unlucky".

I imagine it'd be a common case to either keep retrying forever, or for some set amount of time, which would mean an arbitrary number of retries, as opposed to a fixed count.

[bgreen-litl]

:+1:

I also have a use case where I want to wait for the lock indefinitely (block). I don't mind if I have to specify a special parameter to get the call to block, but as is I don't believe there's any way to guarantee that it will even retry for a minimum amount of time. The full jitter used (0 to the specified retry_delay) means we could potentially give up after a short amount of time even if I set retry_times to some large number.

[Cediddi]

If this project is not dead, I'd like to have this feature too. My use case is same with @bgreen-litl . I need to block the process until lock gets released.

[jheld]

Hopefully the project is not dead.

Does anyone want to put their hat in to ask the maintainer for merge & release permissions/access?

[brainix]

This project looks nice, but if it’s unmaintained, consider using Pottery’s implementation of Redlock. Disclaimer: I develop/maintain Pottery.

Pottery’s context manager blocks and retries indefinitely, mirroring Python’s excellent threading.Lock API, which I believe addresses this issue. If you need more granular control over blocking/timeout behavior, you can call .acquire() directly.

[zhaojiangbing]

没有续命锁