On Wed, Oct 19, 2011 at 6:13 PM, Marko Kreen <markokr@gmail.com> wrote:
> On Wed, Oct 19, 2011 at 3:59 PM, Daniele Varrazzo
> <daniele.varrazzo@gmail.com> wrote:
>> On Wed, Oct 19, 2011 at 1:12 PM, Marko Kreen <markokr@gmail.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.
DB-API 2.0:
.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.
--
marko