From a7dece4f5cb64bc1a7866f61b5f2179d602847e0 Mon Sep 17 00:00:00 2001 From: Michael Wiedinmyer Date: Wed, 23 Jun 2021 19:20:52 -0400 Subject: [PATCH] Fix capitalization --- docs/DistributedLock.Redis.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/DistributedLock.Redis.md b/docs/DistributedLock.Redis.md index 881556c6..07805157 100644 --- a/docs/DistributedLock.Redis.md +++ b/docs/DistributedLock.Redis.md @@ -41,7 +41,7 @@ In addition to specifying the name/key and database(s), some additional tuning o - `Expiry` determines how long the lock will be *initially* claimed for (because of auto-extension, locks can be held for longer). Defaults to 30s. - `ExtensionCadence` determines how frequently the hold on the lock will be renewed to the full `Expiry`. Defaults to 1/3 of `Expiry`. - `MinValidityTime` determines what fraction of `Expiry` still has to remain when the locking operation completes to consider it a success. This is mostly relevant when acquiring a lock across multiple databases (e. g. if we immediately succeed on database 1 and eventually succeed on database 2 after 30s have elapsed, then our hold on database 1 will have expired). Defaults to 90% of the `Expiry`. -- `BusyWaitSleepTime` specifies a range of times that the implementation will sleep between attempts to acquire a lock that is currently held by someone else. A random number in the range will be chosen for each sleep. If you expect contention, lowering these values may increase the responsiveness (how quickly a lock detects that it can now be taken) but will increase the number of calls made to REdis. Raising the values will have the reverse effects. +- `BusyWaitSleepTime` specifies a range of times that the implementation will sleep between attempts to acquire a lock that is currently held by someone else. A random number in the range will be chosen for each sleep. If you expect contention, lowering these values may increase the responsiveness (how quickly a lock detects that it can now be taken) but will increase the number of calls made to Redis. Raising the values will have the reverse effects. 1 The reason RedLock does not work with semaphores is that entering a semaphore on a majority of databases does not guarantee that the semaphore's invariant is preserved. For example, imagine a two-count semaphore with three databases (1, 2, and 3) and three users (A, B, and C). We could find ourselves in the following situation: on database 1, users A and B have entered. On database 2, users B and C have entered. On database 3, users A and C have entered. Here all users believe they have entered the semaphore because they've succeeded on two out of three databases.