On 28.10.2022 18:36, Mike Bayer wrote:
On Fri, Oct 28, 2022, at 12:14 PM, Marc-Andre Lemburg wrote:
Overall, I believe that important settings such as autocommit
should only be set in the connection constructor, since the
semantics change dramatically between autocommit and manual
commit.
oh, that change would be much more intrusive. This defeats the
usability of connection pools, and being able to reset session state on
a connection so that it may be returned to a pool for re-use is a normal
thing. Within the MS ODBC realm Ive just learned of the
sp_reset_connection stored procedure, which seems to be sparsely
documented, but is mentioned as essential for pooling here:
https://learn.microsoft.com/en-us/sql/connect/odbc/linux-mac/using-integrated-authentication?view=sql-server-ver16#tracking-access-to-a-database
<https://learn.microsoft.com/en-us/sql/connect/odbc/linux-mac/using-integrated-authentication?view=sql-server-ver16#tracking-access-to-a-database>
In my application designs, I typically have two or three pools: one for
autoconnect connections, one for manual commit ones and sometimes
one for read-only connections.
In many respects, those types of connections are too different
to safely keep them in the same pool. The optimization settings
also often deep, so it would be too costly to reset them for
placing them into a generic pool.
But those are my 2 cents.
In such a world, we'd only have an autocommit keyword argument
in the Connection constructor and a read-only attribute on the
object to query this after creation.
Such a change could be implemented for a DB-API 3.0. For 2.0,
the ship has sailed already.
So how about going with the above compromise (*) ?
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Experts (#1, Oct 28 2022)
>>> Python Projects, Coaching and Support ... https://www.egenix.com/
>>> Python Product Development ... https://consulting.egenix.com/
________________________________________________________________________
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
https://www.egenix.com/company/contact/
https://www.malemburg.com/
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
https://mail.python.org/mailman/listinfo/db-sig
