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()
|
Список | 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 по дате отправления: