diff --git a/Docs/Basics.md b/Docs/Basics.md index e3bfca9aa..b79a3f0b3 100644 --- a/Docs/Basics.md +++ b/Docs/Basics.md @@ -35,7 +35,7 @@ The object returned from `GetDatabase` is a cheap pass-thru object, and does not object asyncState = ... IDatabase db = redis.GetDatabase(databaseNumber, asyncState); -Once you have the `IDatabase`, it is simply a case of using the [redis API](http://redis.io/commands). Note that all methods have both synchronous and asynchronous implementaions. In line with Microsoft's naming guidance, the asynchronous methods all end `...Async(...)`, and are fully `await`-able etc. +Once you have the `IDatabase`, it is simply a case of using the [redis API](http://redis.io/commands). Note that all methods have both synchronous and asynchronous implementations. In line with Microsoft's naming guidance, the asynchronous methods all end `...Async(...)`, and are fully `await`-able etc. The simplest operation would be to store and retrieve a value: @@ -100,12 +100,12 @@ There are 3 primary usage mechanisms with StackExchange.Redis: - Asynchronous - where the operation completes some time in the future, and a `Task` or `Task` is returned immediately, which can later: - be `.Wait()`ed (blocking the current thread until the response is available) - have a continuation callback added ([`ContinueWith`](http://msdn.microsoft.com/en-us/library/system.threading.tasks.task.continuewith(v=vs.110).aspx) in the TPL) - - be *awaited* (which is a language-level feature that simplfies the latter, while also continuing immediately if the reply is already known) + - be *awaited* (which is a language-level feature that simplifies the latter, while also continuing immediately if the reply is already known) - Fire-and-Forget - where you really aren't interested in the reply, and are happy to continue irrespective of the response The synchronous usage is already shown in the examples above. This is the simplest usage, and does not involve the [TPL][1]. -For asynchronous uage, the key difference is the `Async` suffix on methods, and (typically) the use of the `await` language feature. For example: +For asynchronous usage, the key difference is the `Async` suffix on methods, and (typically) the use of the `await` language feature. For example: string value = "abcdefg"; await db.StringSetAsync("mykey", value); diff --git a/Docs/Configuration.md b/Docs/Configuration.md index 71eb4f8e5..0636e4448 100644 --- a/Docs/Configuration.md +++ b/Docs/Configuration.md @@ -10,7 +10,7 @@ The `configuration` here can be either: - a `ConfigurationOptions` instance - a `string` representing the configuration -The latter is *basically* a tokenized form of the former. +The latter is *basically* a tokenized form of the former. Basic Configuration Strings - @@ -56,7 +56,7 @@ The `ConfigurationOptions` object has a wide range of properties, all of which a | name={string} | `ClientName` | Identification for the connection within redis | | password={string} | `Password` | Password for the redis server | | proxy={proxy type} | `Proxy` | Type of proxy in use (if any); for example "twemproxy" | -| resolveDns={bool} | `ResolveDns` | Specifies that DNS resolution should be explict and eager, rather than implicit | +| resolveDns={bool} | `ResolveDns` | Specifies that DNS resolution should be explicit and eager, rather than implicit | | serviceName={string} | `ServiceName` | Not currently implemented (intended for use with sentinel) | | ssl={bool} | `Ssl` | Specifies that SSL encryption should be used | | sslHost={string} | `SslHost` | Enforces a particular SSL host identity on the server's certificate | diff --git a/Docs/KeysValues.md b/Docs/KeysValues.md index ed542f485..e1c69fb10 100644 --- a/Docs/KeysValues.md +++ b/Docs/KeysValues.md @@ -93,4 +93,4 @@ The response uses the `RedisResult` type (this is unique to scripting; usually t Conclusion --- -The types used in the API are very deliberately chosen to distinguish redis *keys* from *values*. However, in virtually all cases you will not need to directly refer to the unerlying types involved, as conversion operations are provided. +The types used in the API are very deliberately chosen to distinguish redis *keys* from *values*. However, in virtually all cases you will not need to directly refer to the underlying types involved, as conversion operations are provided. diff --git a/Docs/PipelinesMultiplexers.md b/Docs/PipelinesMultiplexers.md index f06766610..ad363390e 100644 --- a/Docs/PipelinesMultiplexers.md +++ b/Docs/PipelinesMultiplexers.md @@ -76,7 +76,7 @@ For this reason, the only redis features that StackExchange.Redis does not offer This achieves the same intent without requiring blocking operations. Notes: - the *data* is not sent via pub/sub; the pub/sub API is only used to notify workers to check for more work -- if there are no workers, the new items remain buffered in the lsit; work does not fall on the floor +- if there are no workers, the new items remain buffered in the list; work does not fall on the floor - only one worker can pop a single value; when there are more consumers than producers, some consumers will be notified and then find there is nothing to do - when you restart a worker, you should *assume* there is work so that you process any backlog - but other than that, the semantic is identical to blocking pops diff --git a/Docs/Profiling.md b/Docs/Profiling.md index 4db092f4e..a4ccac084 100644 --- a/Docs/Profiling.md +++ b/Docs/Profiling.md @@ -43,7 +43,7 @@ Due to StackExchange.Redis's asynchronous interface, profiling requires outside by providing context objects when you start and end profiling (via the `BeginProfiling(object)` & `FinishProfiling(object)` methods), and when a command is sent (via the `IProfiler` interface's `GetContext()` method). -A toy example of assocating commands issued from many different threads together +A toy example of associating commands issued from many different threads together ``` class ToyProfiler : IProfiler diff --git a/Docs/Transactions.md b/Docs/Transactions.md index 0b74430a1..9c4b3f703 100644 --- a/Docs/Transactions.md +++ b/Docs/Transactions.md @@ -2,12 +2,12 @@ ===================== Transactions in Redis are not like transactions in, say a SQL database. The [full documentation is here](http://redis.io/topics/transactions), -but to paraphraise: +but to paraphrase: A transaction in redis consists of a block of commands placed between `MULTI` and `EXEC` (or `DISCARD` for rollback). Once a `MULTI` has been encountered, the commands on that connection *are not executed* - they are queued (and the caller gets the reply `QUEUED` to each). When an `EXEC` is encountered, they are -all applied in a single unit (i.e. without other connections getting time betweeen operations). If a `DISCARD` is seen instead of +all applied in a single unit (i.e. without other connections getting time between operations). If a `DISCARD` is seen instead of a `EXEC`, everything is thrown away. Because the commands inside the transaction are queued, you can't make decisions *inside* the transaction. For example, in a SQL database you might do the following (pseudo-code - illustrative only):