use list tables instead of table.yaml

Author: kay-kim

source/faq/concurrency.txt

@@ -117,7 +117,67 @@ Which operations lock the database?
 The following table lists common database operations and the types of
 locks they use:
 
-.. include:: /includes/table/lock-behavior-per-operation.rst
+.. list-table::
+   :header-rows: 1
+
+   * - Operation
+
+     - Lock Type
+
+   * - Issue a query
+
+     - Read lock
+
+   * - Get more data from a :term:`cursor`
+
+     - Read lock
+
+   * - Insert data
+
+     - Write lock
+
+   * - Remove data
+
+     - Write lock
+
+   * - Update data
+
+     - Write lock
+
+   * - :term:`Map-reduce <map-reduce>`
+
+     - Read lock and write lock, unless operations are specified as
+       non-atomic. Portions of map-reduce jobs can run concurrently.
+       
+
+   * - Create an index
+
+     - Building an index in the foreground, which is the default, locks
+       the database for extended periods of time.
+       
+
+   * - :method:`db.eval()`
+
+     - Write lock. The :method:`db.eval()` method takes a global write
+       lock while evaluating the JavaScript function. 
+       To avoid taking this global write lock, you can
+       use the :dbcommand:`eval` command with ``nolock: true``.
+       
+
+   * - :dbcommand:`eval`
+
+     - Write lock. By default, :dbcommand:`eval` command takes a global
+       write lock while evaluating the JavaScript function. If used
+       with ``nolock: true``, the :dbcommand:`eval`
+       command does *not* take a global write lock while evaluating
+       the JavaScript function. However, the logic within the
+       JavaScript function may take write locks for write operations.
+       
+
+   * - :method:`~db.collection.aggregate()`
+
+     - Read lock
+
 
 Which administrative commands lock the database?
 ------------------------------------------------