7 ms·

That doesn’t make sense, they can’t assume the lock is freed after the timeout. They have to retry to get the lock again, because another process might have tak

That doesn’t make sense, they can’t assume the lock is freed after the timeout. They have to retry to get the lock again, because another process might have taken the lock. Also, redis is single threaded so access to redis is by definition serialized.

codegladiator 3y ago
The lock is explicitly release by the redis server itself after the ttl. It's not that the Client will assume that the lock is released.
- xiwenc 3y ago
  In the past i used SQS where the client can extend the TTL of a given message (or lock in this case?) while it is still alive. Isn’t that possible with Redis?
  - TheCycoONE 3y ago
    It is, with quite a bit of flexibility https://redis.io/commands/expire/ https://redis.io/commands/expire/
cbzoiav 3y ago
As the other guy says the lock is released by the server. If you don't have a mechanism to release it after a timeout, what happens if a node fails?
- Salgat 3y ago
  RedLock automatically releases a lock after a given timeout. The server can just release it early or refresh it also.
  - cbzoiav 3y ago
    Yes, which is what I said. But now you have a released lock and a client that thinks they have the lock.