On Wed, Oct 19, 2011 at 6:13 PM, Marko Kreen <markokr(at)gmail(dot)com> wrote:
> On Wed, Oct 19, 2011 at 3:59 PM, Daniele Varrazzo
> <daniele(dot)varrazzo(at)gmail(dot)com> wrote:
>> On Wed, Oct 19, 2011 at 1:12 PM, Marko Kreen <markokr(at)gmail(dot)com> wrote:
>> Well, you know the middleware much better than me: I was assuming that
>> if pgpool discards connection returned idle in transaction to the pool
>> you have very strong reasons :) I just want to optimize the
>> communication between the driver and the middleware: what do you think
>> the "protocol" between psycopg and pgpool should be?
> Thats easy - do not rollback.
Let's clarify that further - DB-API *MUST* say that .close()
[and also .__del__()] will rollback. Eg - imagine
driver accessing .dbf / .csv files directly.
But there is no good reason to require communication
with backend if the backend will rollback anyway
on connection close.
Close the connection now (rather than whenever __del__ is
called). The connection will be unusable from this point
forward; an Error (or subclass) exception will be raised
if any operation is attempted with the connection. The
same applies to all cursor objects trying to use the
connection. Note that closing a connection without
committing the changes first will cause an implicit
rollback to be performed.
From my reading, .close() and .__del__() *are* equivalent,
and no explicit communication is required, if the backend
will rollback anyway on connection close.
Not that I'm against breaking DB-API if the wording is insane,
but the wording seems to direct towards sane behaviour.
In response to
psycopg by date
|Next:||From: Daniele Varrazzo||Date: 2011-10-19 18:34:11|
|Subject: Re: Rollback on close [Was: Fwd: [DB-SIG] conn.close() idempotence]|
|Previous:||From: Daniele Varrazzo||Date: 2011-10-19 17:08:02|
|Subject: Re: Error: no Python Codec for client encoding|