Problems after upgrading from 7.4.6 driver to 8.0.2 driver

Lists: pgsql-jdbc
From: Mark Lewis <mark(dot)lewis(at)mir3(dot)com>
To: pgsql-jdbc(at)postgresql(dot)org
Subject: Problems after upgrading from 7.4.6 driver to 8.0.2 driver
Date: 2005-04-25 23:38:43
Message-ID: 1114472323.923.56.camel@amateljan.mirlogic.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-jdbc

After upgrading from pg74.215.jdbc3.jar to postgresql-8.0-310.jdbc3.jar,
I've encountered problems getting a "This statement has been closed"
exception when using a PreparedStatement.

The application is using Jakarta's DBCP 1 connection pooling with
prepared statement caching, and is configured to execute "select 1" each
time a connection is checked out from the pool to ensure that the
connection is still alive, so I'm pretty sure the server connection is
still good.

Are there any known gotchas migrating to the new server prepared
statement implementation? Something that could be causing statements to
close when they otherwise would not be?

Thanks,
Mark Lewis

Thanks,
Mark Lewis


From: Mark Lewis <mark(dot)lewis(at)mir3(dot)com>
To: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Problems after upgrading from 7.4.6 driver to 8.0.2
Date: 2005-04-26 00:00:37
Message-ID: 1114473637.923.75.camel@amateljan.mirlogic.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-jdbc

Sorry for the noise, just after posting I finally tracked it down to a
problem in the application. In one code path a prepared statement was
being double-closed, which apparently triggers a bug in the version of
DBCP being used.

I'm still not sure why it only started misbehaving after upgrading the
JDBC driver.

-- Mark

On Mon, 2005-04-25 at 16:38, Mark Lewis wrote:
> After upgrading from pg74.215.jdbc3.jar to postgresql-8.0-310.jdbc3.jar,
> I've encountered problems getting a "This statement has been closed"
> exception when using a PreparedStatement.
>
> The application is using Jakarta's DBCP 1 connection pooling with
> prepared statement caching, and is configured to execute "select 1" each
> time a connection is checked out from the pool to ensure that the
> connection is still alive, so I'm pretty sure the server connection is
> still good.
>
> Are there any known gotchas migrating to the new server prepared
> statement implementation? Something that could be causing statements to
> close when they otherwise would not be?
>
> Thanks,
> Mark Lewis
>
> Thanks,
> Mark Lewis
>
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster