Redlock or how to implement locking of critical code sections by means of cashews

[rkrell]

I use the following wrapper of an AsyncGenerator to the cache.lock() function:

@asynccontextmanager
async def critical_section_lock_cleanup_items():
    key = get__key_lock_cleanup_items()
    async with cache.lock(key, expire=LEASE_BS_REDLOCK_CLEANUP_ITEMS):
        yield

On calling this by

async with critical_section_lock_cleanup_items():
     # critical code section
     # ...

I get quite often a LockedError:

Traceback (most recent call last):
  ...
  File "/home/elentory/lib/python3.7/contextlib.py", line 170, in __aenter__
    return await self.gen.__anext__()
  File "/home/user/automation/utils/redis.py", line 93, in critical_section_lock_cleanup_items
    async with cache.lock(key, expire=LEASE_BS_REDLOCK_CLEANUP_ITEMS):
  File "/home/user/lib/python3.7/contextlib.py", line 170, in __aenter__
    return await self.gen.__anext__()
  File "/home/user/automation/lib/python3.7/site-packages/cashews/backends/interface.py", line 163, in lock
    raise LockedError(f"Key {key} already locked")
cashews.exceptions.LockedError: Key lock_cleanup_items already locked

Do I have to implement some kind of "active" waiting for the lock to disappear in critical_section_lock_cleanup_items(). What would be the best way here?

[Krukov]

Hi,
No currently 'lock' context manager do not have such functionality and I agree that is weird, Also I found out that decorator locked also have a problem with a race condition and could "brake down" a lock .
So I don't have solution for you now, but I gonna add it

[Krukov]

Changed in 5.3.2 - added wait parameter for lock context manager (False by default)

[rkrell]

Thanks a lot!