Clarification around locking (#3853)

This commit is contained in:
Preetha 2018-02-01 14:08:06 -06:00 committed by GitHub
parent 842ae5a248
commit 6d969d372b
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 7 additions and 1 deletions

View File

@ -186,7 +186,9 @@ The table below shows this endpoint's support for
A key does not need to exist to be acquired. If the lock is already held by A key does not need to exist to be acquired. If the lock is already held by
the given session, then the `LockIndex` is not incremented but the key the given session, then the `LockIndex` is not incremented but the key
contents are updated. This lets the current lock holder update the key contents are updated. This lets the current lock holder update the key
contents without having to give up the lock and reacquire it. contents without having to give up the lock and reacquire it. **Note that an update
that does not include the acquire parameter will proceed normally even if another
session has locked the key.**
- `release` `(string: "")` - Specifies to use a lock release operation. This is - `release` `(string: "")` - Specifies to use a lock release operation. This is
useful when paired with `?acquire=` as it allows clients to yield a lock. This useful when paired with `?acquire=` as it allows clients to yield a lock. This

View File

@ -143,3 +143,7 @@ Clients should also watch the key using a blocking query for any
changes. If the leader steps down or fails, the `Session` associated changes. If the leader steps down or fails, the `Session` associated
with the key will be cleared. When a new leader is elected, the key with the key will be cleared. When a new leader is elected, the key
value will also be updated. value will also be updated.
Using the `acquire` param is optional. This means
that if you use leader election to update a key, you must not update the key
without the acquire parameter.