.

diff --git a/doc/build/content/dbengine.txt b/doc/build/content/dbengine.txt
index ba3965baafe1c41ab5a3f60753c006d7a53d4058..21ce8d4068c6c7b5369fcb3c06fc6d309f7766dd 100644 (file)
--- a/doc/build/content/dbengine.txt
+++ b/doc/build/content/dbengine.txt
@@ -246,7 +246,7 @@ The purpose of the "implicit" connection is strictly one of convenience; while i
 
 The internal behavior of engine during implicit execution can be affected by the `strategy` keyword argument to `create_engine()`.  Generally this setting can be left at its default value of `plain`.  However, for the advanced user, the `threadlocal` option can provide the service of managing connections against the current thread in which they were pulled from the connection pool, where the same underlying DBAPI connection as well as a single database-level transaction can then be shared by many operations without explicitly passing a `Connection` or `Transaction` object around.  It also may reduce the number of connections checked out from the connection pool at a given time.
 
-Note that this setting does **not** affect the fact that **Connection and Transaction objects are not threadsafe.**.  The "threadlocal" strategy affects the selection of DBAPI connections which are pulled from the connection pool when a `Connection` object is created, but does not synchronize method access to the `Connection` or `Transaction` instances themselves, which are only proxy objects.  It is instead intended that many `Connection` instances would share access to a single "connection" object that is referenced in relation to the current thread.
+Note that this setting does **not** affect the fact that **Connection and Transaction objects are not threadsafe.**  The "threadlocal" strategy affects the selection of DBAPI connections which are pulled from the connection pool when a `Connection` object is created, but does not synchronize method access to the `Connection` or `Transaction` instances themselves, which are only proxy objects.  It is instead intended that many `Connection` instances would share access to a single "connection" object that is referenced in relation to the current thread.
 
 When `strategy` is set to `plain`, each implicit execution requests a unique connection from the connection pool, which is returned to the pool when the resulting `ResultProxy` falls out of scope (i.e. `__del__()` is called) or its `close()` method is called.  If a second implicit execution occurs while the `ResultProxy` from the previous execution is still open, then a second connection is pulled from the pool.