From 25a827a46c4958ebc439ad531f259167a2d9c3ed Mon Sep 17 00:00:00 2001 From: Tony Hannan Date: Wed, 13 Jul 2011 16:04:37 -0400 Subject: [PATCH] small edit to article --- doc/Article1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/Article1.md b/doc/Article1.md index e2a3c19..c5ee020 100644 --- a/doc/Article1.md +++ b/doc/Article1.md @@ -17,7 +17,7 @@ You may want to define fields ahead of time to help catch typos. For example, yo ### Pipelining -To increase concurrency on a server connection and thus speed up threads sharing it, I pipeline requests over a connection, a' la [HTTP pipelining](http://en.wikipedia.org/wiki/HTTP_pipelining). Pipelining means sending multiple requests over the socket and receiving the responses later in the same order. This is faster than sending one request, waiting for the response, then sending the next request, and so on. The pipelining implementation uses [futures/promises](http://en.wikipedia.org/wiki/Futures_and_promises), which are simply implemented as IO actions. You are not exposed to the pipelining, because it is internal to *Cursor*, which iterates over the results of a query. More specifically, a query returns its cursor right away, locking the socket only briefly to write the request (allowing other threads to issue their queries). When a cursor is asked for its first result, it waits for the query response from the server. Also, when a cursor returns the last result of the current batch, it asynchronously requests the next batch from the server. This asynchronicity is automatic because the request returns a promise right away that the cursor will wait on when asked for the next result. +To increase concurrency on a server connection and thus speed up threads sharing it, I pipeline requests over a connection, a' la [HTTP pipelining](http://en.wikipedia.org/wiki/HTTP_pipelining). Pipelining means sending multiple requests over the socket and receiving the responses later in the same order. This is faster than sending one request, waiting for the response, then sending the next request, and so on. The pipelining implementation uses [futures/promises](http://en.wikipedia.org/wiki/Futures_and_promises), which are simply implemented as IO actions. You are not exposed to the pipelining, because it is internal to *Cursor*, which iterates over the results of a query. Internally, a query returns its cursor right away, locking the socket only briefly to write the request (allowing other threads to issue their queries). When a cursor is asked for its first result, it waits for the query response from the server. Also, when a cursor returns the last result of the current batch, it asynchronously requests the next batch from the server. This asynchronicity is automatic because the request returns a promise right away that the cursor will wait on when asked for the next result. ### DB Action