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()  (Oliver Jowett <oliver@opencloud.com>)
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:

Previous
From: Dave Cramer
Date:
Subject: Re: Problem with PGStatement.getLastOID()
Next
From: ListMan
Date:
Subject: Re: Problem with PGStatement.getLastOID()