From 2ad884abeec91a2b28faa0962f0bf38803323461 Mon Sep 17 00:00:00 2001 From: Dan Frost Date: Wed, 26 Nov 2014 12:49:53 +0000 Subject: [PATCH] docs: internals/sessions: minor fixes --- website/source/docs/internals/sessions.html.markdown | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/website/source/docs/internals/sessions.html.markdown b/website/source/docs/internals/sessions.html.markdown index 62f451e64..7daea5ae8 100644 --- a/website/source/docs/internals/sessions.html.markdown +++ b/website/source/docs/internals/sessions.html.markdown @@ -64,9 +64,9 @@ systems to be built that require an operator to intervene in the case of a failure, but preclude the possibility of a split-brain. The final nuance is that sessions may provide a `lock-delay`. This -is a time duration, between 0 and 60 second. When a session invalidation +is a time duration, between 0 and 60 seconds. When a session invalidation takes place, Consul prevents any of the previously held locks from -being re-acquired for the `lock-delay` interval; this is a safe guard +being re-acquired for the `lock-delay` interval; this is a safeguard inspired by Google's Chubby. The purpose of this delay is to allow the potentially still live leader to detect the invalidation and stop processing requests that may lead to inconsistent state. While not a @@ -79,7 +79,7 @@ mechanism by providing a zero delay value. Integration between the Key/Value store and sessions are the primary place where sessions are used. A session must be created prior to use, -and is then referred to by it's ID. +and is then referred to by its ID. The Key/Value API is extended to support an `acquire` and `release` operation. The `acquire` operation acts like a Check-And-Set operation, except it @@ -93,7 +93,7 @@ since the request will fail if given an invalid session. A critical note is that the lock can be released without being the creator of the session. This is by design, as it allows operators to intervene and force terminate a session if necessary. As mentioned above, a session invalidation will also -cause all held locks to be released. When a lock is released, the `LockIndex`, +cause all held locks to be released. When a lock is released, the `LockIndex` does not change, however the `Session` is cleared and the `ModifyIndex` increments. These semantics (heavily borrowed from Chubby), allow the tuple of (Key, LockIndex, Session) @@ -103,7 +103,7 @@ is incremented on each `acquire`, even if the same session re-acquires a lock, the `sequencer` will be able to detect a stale request. Similarly, if a session is invalided, the Session corresponding to the given `LockIndex` will be blank. -To make clear, this locking system is purely *advisory*. There is no enforcement +To be clear, this locking system is purely *advisory*. There is no enforcement that clients must acquire a lock to perform any operation. Any client can read, write, and delete a key without owning the corresponding lock. It is not the goal of Consul to protect against misbehaving clients.