X-Git-Url: https://git.saurik.com/redis.git/blobdiff_plain/76d31044d44c7adb4af71dd273b52ec9a4768e17..49128f0b9da725de992e427fa341a837bcc2991b:/doc/SetnxCommand.html
diff --git a/doc/SetnxCommand.html b/doc/SetnxCommand.html
index 91f9206d..8c47e72d 100644
--- a/doc/SetnxCommand.html
+++ b/doc/SetnxCommand.html
@@ -41,6 +41,7 @@ SETNX lock.foo <current UNIX time + lock timeout + 1>
- C1 and C2 read lock.foo to check the timestamp, because SETNX returned 0 to both C1 and C2, as the lock is still hold by C3 that crashed after holding the lock.
- C1 sends DEL lock.foo
- C1 sends SETNX => success!
- C2 sends DEL lock.foo
- C2 sends SETNX => success!
- ERROR: both C1 and C2 acquired the lock because of the race condition.
Fortunately it's possible to avoid this issue using the following algorithm.Let's see how C4, our sane client, uses the good algorithm:
- C4 sends SETNX lock.foo in order to acquire the lock
- The crashed C3 client still holds it, so Redis will reply with 0 to C4.
- C4 GET lock.foo to check if the lock expired. If not it will sleep one second (for instance) and retry from the start.
- If instead the lock is expired because the UNIX time at lock.foo is older than the current UNIX time, C4 tries to perform GETSET lock.foo <current unix timestamp + lock timeout + 1>
- Thanks to the GETSET command semantic C4 can check if the old value stored at key is still an expired timestamp. If so we acquired the lock!
- Otherwise if another client, for instance C5, was faster than C4 and acquired the lock with the GETSET operation, C4 GETSET operation will return a non expired timestamp. C4 will simply restart from the first step. Note that even if C4 set the key a bit a few seconds in the future this is not a problem.
+IMPORTANT NOTE: In order to make this locking algorithm more robust, a client holding a lock should always check the timeout didn't expired before to unlock the key with DEL because client failures can be complex, not just crashing but also blocking a lot of time against some operation and trying to issue DEL after a lot of time (when the LOCK is already hold by some other client).