Re: Problem with PGStatement.getLastOID()

Поиск
Список
Период
Сортировка
От Oliver Jowett
Тема Re: Problem with PGStatement.getLastOID()
Дата
Msg-id 20031202013105.GD19205@opencloud.com
обсуждение исходный текст
Ответ на Re: Problem with PGStatement.getLastOID()  (ListMan <listman@cybermaccara.com>)
Ответы Re: Problem with PGStatement.getLastOID()  (ListMan <listman@cybermaccara.com>)
Список 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

В списке pgsql-jdbc по дате отправления:

Предыдущее
От: ListMan
Дата:
Сообщение: Re: Problem with PGStatement.getLastOID()
Следующее
От: ListMan
Дата:
Сообщение: Re: Problem with PGStatement.getLastOID()