Re: Problem with PGStatement.getLastOID() - Mailing list pgsql-jdbc
From | ListMan |
---|---|
Subject | Re: Problem with PGStatement.getLastOID() |
Date | |
Msg-id | 6.0.1.1.0.20031202014616.01d57010@mail.cybermaccara.com Whole thread Raw |
In response to | Re: Problem with PGStatement.getLastOID() (Oliver Jowett <oliver@opencloud.com>) |
Responses |
Re: Problem with PGStatement.getLastOID()
|
List | pgsql-jdbc |
At 01:25 2.12.2003, Oliver Jowett wrote: >Your comment above implies you're using a connection pool; is it possible >that you're actually getting a wrapper Connection/Statement implemented by >the pool infrastructure, rather than the Connection/Statement objects handed >out by the driver directly? What is the concrete class of 'stmt' reported in >the ClassCastException? Yes, we have implemented connection pool in Tomcat. from server.xml: <Resource name="jdbc/reltest" scope="Shareable" type="org.postgresql.jdbc3.Jdbc3PoolingDataSource" auth="Container"/> <ResourceParams name="jdbc/reltest"> <parameter><name>factory</name><value>org.postgresql.jdbc3.Jdbc3ObjectFactory</value></parameter> <parameter><name>initialConnections</name><value>1</value></parameter> <parameter><name>maxConnections</name><value>1000</value></parameter> <parameter><name>dataSourceName</name><value>reltest</value></parameter> <parameter><name>serverName</name><value>localhost</value></parameter> ...etc and only thing I change when switching drivers is the serverName parameter between localhost and our prod server. Above configuration hasn't changed in a loooong time. Datasource handling: protected org.postgresql.jdbc3.Jdbc3PoolingDataSource source = null; void init() { Context initCtx = null; Context envCtx = null; initCtx = new InitialContext(); envCtx = (Context) initCtx.lookup("java:comp/env"); source = (org.postgresql.jdbc3.Jdbc3PoolingDataSource) envCtx.lookup("jdbc/reltest"); } Conenction getCon() { Connection con = source.getConnection(); con.setAutoCommit(true); return con; } And that connection I have used in the code snippet I posted previously. These also haven't changed in a long time. I don't get much out of the exception except stack trace: Entity.executeUpdate: java.lang.ClassCastException java.lang.ClassCastException at com.like.entity.Entity.executeUpdate(Entity.java:180) at com.like.entity.Document.save(Document.java:686) at org.apache.jsp.DocumentEditView$jsp._jspService(DocumentEditView$jsp.java:181) ... >Alternatively it may be a classloading difference between the two machines >-- the cast will fail if your code and the JDBC code use versions of >org.postgresql.PGStatement loaded by different classloaders. ALL code is running locally in my environment in single JVM. Only thing changed between tests is pgsql server address and jdbc-driver. Although, I've had problems with tomcat before with connection pooling, so that's not too far fetched except that this installation indeed is completely running on my machine. >Either way, it sounds like the two environments differ by more than just >driver versions. Try the 7.3 drivers you use in production on your Cygwin >box (against a 7.3 server if necessary) and see if you get the same failure. Yes, that is what I have to do just to rule any discrepansies in that out. I'm not expecting much of a result since this problem originates from tomcat/netbeans/java/jdbc in some way. Most likely my configuration is foobared in a way it works with 7.3 but not anymore with newer drivers... ;) Nevertheless, this is something I have to get solved... Thanks for your suggestions! Hopefully someone can help me track this down. B Rgds, JariP
pgsql-jdbc by date: