X-Original-To: pgsql-admin-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id 32BCBD1D299 for ; Sun, 15 Feb 2004 17:11:07 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024) with ESMTP id 34019-03 for ; Sun, 15 Feb 2004 13:11:04 -0400 (AST) Received: from dg.eisolution.com (adsl-64-108-8-141.dsl.chcgil.ameritech.net [64.108.8.141]) by svr1.postgresql.org (Postfix) with ESMTP id 6E6E3D1DAA7 for ; Sun, 15 Feb 2004 13:10:58 -0400 (AST) Received: from MarcM8500 (c-24-14-246-6.client.comcast.net [24.14.246.6]) (authenticated) by dg.eisolution.com (8.11.6/8.11.6) with ESMTP id i1FHBiO20611; Sun, 15 Feb 2004 11:11:44 -0600 From: "Marc Mitchell" To: "'Warren Little'" , Subject: Re: idle in transaction Date: Sun, 15 Feb 2004 11:10:50 -0600 Message-ID: <001501c3f3e6$aa530120$6901a8c0@MarcM8500> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <1076862212.3148.9.camel@localhost.localdomain> Importance: Normal X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200402/226 X-Sequence-Number: 12400 We see the exact same condition when setting "setAutoCommit(FALSE)". However, we expected that situation based on what we understand as the way such a setting manifests itself within the Multi-Statement-Transaction handling of Postgres. Furthermore, we saw this exact same behavior under at least 7.3.4, if not 7.3.2 and maybe even 7.2.something. So long as the idled transaction isn't holding any locks on any data resources, I don't know if this condition is a bad thing. It would be nice to be able to differentiate between a transaction that has been "declared" but has yet to really begin issuing any statements and take locks from transactions that are idle "mid-transaction". The latter of which spells death for a multi-user, OLTP application. I'll be curious to hear others experience with this. Marc Mitchell Enterprise Information Solutions, Inc. Downers Grove, IL 60515 marcm@eisolution.com -----Original Message----- From: pgsql-admin-owner@postgresql.org [mailto:pgsql-admin-owner@postgresql.org] On Behalf Of Warren Little Sent: Sunday, February 15, 2004 10:24 AM To: pgsql-admin@postgresql.org Subject: [ADMIN] idle in transaction We recently upgraded postgres from 7.3 to 7.4, along with the JDBC jar, and noticed all the backend processes/connections are left in the "idle in transaction" state where before they where left in the "idle" state. Has something changed in the 7.4 jdbc driver vs 7.3 which might be causing this? Note We call setAutoCommit(FALSE) on every connection when created. -- Warren Little Senior Vice President Secondary Marketing Security Lending Wholesale, LC www.securitylending.com Tel: 866-369-7763 Fax: 866-849-8082 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org