From: Mike Bayer Date: Sun, 22 Oct 2006 02:06:43 +0000 (+0000) Subject: . X-Git-Tag: rel_0_3_0~6 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=49539ae4b8ffc1baa1ff73309c470b3d5a381e72;p=thirdparty%2Fsqlalchemy%2Fsqlalchemy.git . --- diff --git a/doc/build/content/dbengine.txt b/doc/build/content/dbengine.txt index ba3965baaf..21ce8d4068 100644 --- 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.