Skip site navigation (1) Skip section navigation (2)

Re: "Idle in Transaction" revisited.

From: Gaetano Mendola <mendola(at)bigfoot(dot)com>
To: Oliver Jowett <oliver(at)opencloud(dot)com>
Cc: John R Pierce <pierce(at)hogranch(dot)com>, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: "Idle in Transaction" revisited.
Date: 2004-09-18 13:50:34
Message-ID: 414C3D2A.4060002@bigfoot.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Oliver Jowett wrote:
| Gaetano Mendola wrote:
|
|> John R Pierce wrote:
|>
|>> I'm curious what common practice is for threads that do nothing but
|>> SELECTS... do folks just enable auto_commit, thereby preventing
|>> pgJDBC from doing BEGIN; ?  Do they lace their code with COMMIT() calls?
|>
|>
|>
|> We were bitten by this problem too, and my solution was to suggest our
|> developer to do and explicit: "ABORT" after the connection, and do
|> explicit "BEGIN"   "END"  instead of rely on the jdbc interface.
|
|
| This is a pretty bad idea as it can confuse the driver's idea of the
| current transaction state. For example, cursor-based resultsets won't
| ever be used if you do your own transaction demarcation in this way.

Fortunatelly I do not use cursors otherwise I could find it out long time ago,
this was the only solution since the 6.x version, and is working well at
least in my applications.
BTW also the python drivers were ( are ? ) affected by this "idle in transaction"
phenomenon and the jdbc 7.4 series too.


Regards
Gaetano Mendola





-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBTD0p7UpzwH2SGd4RAr1nAKCmtDjy8TWAMP/vhC+Kcn+7/XZEOgCgvLN4
YEWFotidXi46eF2rfOpywWc=
=XFRs
-----END PGP SIGNATURE-----


In response to

pgsql-jdbc by date

Next:From: Francisco Figueiredo Jr.Date: 2004-09-18 14:30:45
Subject: Issues regarding code license of ported code.
Previous:From: Oliver JowettDate: 2004-09-18 10:53:26
Subject: Re: "Idle in Transaction" revisited.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group