Re: Problem with PGStatement.getLastOID()

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: ListMan <listman(at)cybermaccara(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Problem with PGStatement.getLastOID()
Date: 2003-12-02 01:31:05
Message-ID: 20031202013105.GD19205@opencloud.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

On Tue, Dec 02, 2003 at 03:16:41AM +0200, ListMan wrote:
> At 02:38 2.12.2003, you wrote:
> >Can you print stmt.getClass() just before the cast then? (usually you'll
> >get
> >the concrete class name in the exception, not sure why it's not there in
> >this case).
>
> Well, "System.out.println("stmt.class: " + stmt.getClass());" just before
> the cast produced:
> stmt.class: class $Proxy1

Ok, it's connection pooling at fault then -- '$Proxy1' will be a
reflection-based dynamic proxy class that wraps the actual Statement object
returned by the driver.

i.e. the reason you can't cast the statement to PGStatement is that it
really isn't a PGStatement, but a java.lang.reflect.Proxy instance generated
by the pooling code that probably only implements java.sql.Statement.

Unfortunately I can't see a simple way of avoiding this problem short of
turning off connection pooling or modifying the pooling code itself (the
latter could probably be done generically by making the proxy implement all
interfaces present on the underlying object).

I don't know why it works on your production system though; is there any
difference in JVM or Tomcat version on the two systems that might affect how
the pooling code behaves?

-O

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message ListMan 2003-12-02 02:20:45 Re: Problem with PGStatement.getLastOID()
Previous Message ListMan 2003-12-02 01:16:41 Re: Problem with PGStatement.getLastOID()