Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #81696 > unrolled thread

Re: Db transactions and locking

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Db transactions and locking Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-11-28 12:28 -0500

#81696 — Re: Db transactions and locking

On Fri, 28 Nov 2014 08:57:07 +0200, "Frank Millman" <frank@chagford.com>
declaimed the following:

>
>My guess now is that the connection is in one of two states - a transaction 
>is active, or it is not. If a command is issued, and a transaction is not 
>active, then a transaction is started. If a conn.commit() or a 
>conn.rollback() is issued, the command is passed up to the database, and the 
>connection state is reset to not active.
>
	Though you may find some adapters have fits working the DB-API
preferences into the engines preference...

	I think SQLite3 is one of those -- given its multilayer locking scheme
it prefers to treat pure SELECT operations as "outside of transaction",
starting a transaction on UPDATE/INSERT/DELETE operations. An adapter to a
different engine might start a transaction on the first SELECT.

	Which is why I tend to stuff in con.commit() calls anywhere that there
may be a gap of time between even two SELECT operations -- ensures nothing
might block another task from accessing the database.

{BTW: my earlier comment was not about the behavior seen, but about the
statement of not seeing anything about it in the documentation}
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web