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


Groups > comp.lang.python > #81622

Db transactions and locking

From "Frank Millman" <frank@chagford.com>
Subject Db transactions and locking
Date 2014-11-27 12:24 +0200
Newsgroups comp.lang.python
Message-ID <mailman.16363.1417083886.18130.python-list@python.org> (permalink)

Show all headers | View raw


Hi all

I just learned something about database transactions, locking, and DB-API 
2.0.

I wondered why a PostgreSQL statement was hanging. On investigation, it was 
waiting to acquire a lock. On further investigation, the lock was held by a 
simple SELECT statement. This surprised me.

I got a clue from a message on the PostgreSQL mailing list -

"PostgreSQL by default commits between each statement unless you explicitly 
start a transaction."

All Python database adaptors that I have used start a transaction when you 
open a cursor. I have just re-read DB-API 2.0, and I cannot see anything 
that specifies this behaviour, but AFAICT this is what happens.

I started to monitor the locks that PostgreSQL holds while I was running my 
application, and sure enough, the lock table grew and grew, even though I 
was only issuing SELECTs. I use a connection pool, so I never actually close 
the connections. If I did I am fairly sure the locks would be released.

I changed my application to call conn.commit() every time I return a 
connection back to the pool, and PostgreSQL shows all the locks being 
released straight away, so I think this has solved the problem.

I don't know if Sql Server and sqlite3 behave the same, but I don't think it 
can do any harm, so I let it apply across the board.

Can anyone see any problem with this?

Frank Millman


Back to comp.lang.python | Previous | Next | Find similar | Unroll thread


Thread

Db transactions and locking "Frank Millman" <frank@chagford.com> - 2014-11-27 12:24 +0200

csiph-web