[DB-SIG] autocommit support in pep-249

Daniele Varrazzo daniele.varrazzo at gmail.com
Wed Sep 14 00:01:05 CEST 2011

On Tue, Sep 13, 2011 at 6:53 PM, Chris Clark <Chris.Clark at ingres.com> wrote:

> You made an interesting comment on the autocommit request, "It shouldn't
> even reach the database". I think you are saying the "set auto commit on"
> request should not be sent to the DBMS and be handled by the driver when
> there are open transactions. If I modify your example slightly:
> conn.begin()
> curs.execute('issue server non transaction based directive ')  # i.e. not
> dml, not ddl
> curs.execute('issue session directive ')  # for example change session
> language of error messages, Oracle NLS settings
> conn.autocommit()
> What should be the behavior be in this instance? No exception being raised
> makes the most sense to me as we are not in a transaction, I'm unclear how
> the driver could make this decision unless it parses and understands each
> curs.execute call.

I think with Postgres the situation is slightly easier, as there is no
"non transaction" statement: any statement including DML is
transactional except a couple (such as CREATE DATABASE) that would
raise an error if run inside a transaction. Because the situation is
this simple, psycopg can just run a BEGIN before the first statement
executed, whatever it is, and there is no need to parse it; it then
knows the state of the connection and an error such as switching to
autocommit while in transaction is indeed handled by the adapter
without calling the backend.

What does the Oracle adapter currently do? From my interpretation of
the dbapi there is no explicit conn.begin(), a transaction is
implicitly started at the first statement. How does the driver
implement this behaviour? Is it something it can delegate to the

Ditto for ODBC, where parsing the statements would be not impratical
but just impossible: how does the adapter currently implement the "not
autocommit" default dbapi behaviour? Is the begin handled by the
adapter or by the backend?

-- Daniele

More information about the DB-SIG mailing list