From e44193f963b0cd9b698caae3f3869d3513a802c9 Mon Sep 17 00:00:00 2001 From: Tony Hannan Date: Wed, 13 Jul 2011 16:03:14 -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 789d595..e2a3c19 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 an 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. 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. ### DB Action