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