Jdbc connection pooling and PG 7.4 consistently fails

On Thu, 18 Dec 2003, Lewis Foti wrote:

Hi

Having downloaded and installed the rpms for 7.4 I upgraded the database and
began testing. As the system under development is based on servlets we are
using the JDBC3 Jdbc3PoolingDataSource to provide the connections. All
attempts to read from the database via jdbc pooled connections now fail.
Looking in syslog the following error is being reported;

Dec 18 19:06:04 neptune postgres[1986]: [4-1] LOG: statement: set
autocommit = off;
Dec 18 19:06:04 neptune postgres[1986]: [5-1] ERROR: SET AUTOCOMMIT TO OFF
is no longer supported

This then causes a Java exception and the query fails. The jdbc jar file
being used is /usr/share/pgsql/pg73jdbc3.jar as provided in the
postgresql-jdbc-7.4-0.5PGDG rpm. Is this the correct one to use or should we
replace it with the /usr/share/pgsql/devpgjdbc3.jar?

The RPMs do not have the correct jar file. Try one of those available
from http://jdbc.postgresql.org/download.html

Kris Jurka

On Friday 19 December 2003 01:27 pm, Kris Jurka wrote:

The RPMs do not have the correct jar file. Try one of those available
from http://jdbc.postgresql.org/download.html

At the time I put the RPMs together there were no 'stable' 7.4 jars, so I
grabbed the dev jars and the 7.3 jars and packaged those. The 7.4.1 packages
will have the 7.4 jars since they are now available.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu

On Fri, 19 Dec 2003, Lamar Owen wrote:

On Friday 19 December 2003 01:27 pm, Kris Jurka wrote:

The RPMs do not have the correct jar file. Try one of those available
from http://jdbc.postgresql.org/download.html

At the time I put the RPMs together there were no 'stable' 7.4 jars, so I
grabbed the dev jars and the 7.3 jars and packaged those. The 7.4.1 packages
will have the 7.4 jars since they are now available.

There's always a stable version in souce form. I take it you don't have a
java compiler handy and/or don't want to make the source rpms dependent on
everyone having these tools available? Still shipping random jar files
with a 7.4 labeled package isn't the best thing to do. Right now the 7.4
stable listed jars available for download aren't up to date with what is
in cvs. If you are unwilling/unable to compile these yourself please send
me or another jdbc developer an email and we'll make sure you've got the
right binaries. For now you could use http://www.ejurka.com/pgsql/jars/

Kris Jurka

On Friday 19 December 2003 04:11 pm, Kris Jurka wrote:

On Fri, 19 Dec 2003, Lamar Owen wrote:

On Friday 19 December 2003 01:27 pm, Kris Jurka wrote:

The RPMs do not have the correct jar file. Try one of those available
from http://jdbc.postgresql.org/download.html

At the time I put the RPMs together there were no 'stable' 7.4 jars, so I
grabbed the dev jars and the 7.3 jars and packaged those. The 7.4.1
packages will have the 7.4 jars since they are now available.

There's always a stable version in souce form. I take it you don't have a
java compiler handy and/or don't want to make the source rpms dependent on
everyone having these tools available?

Mostly to let others use them without having to have a full java toolchain. I
personally need the right toolchain, but haven't gone through the steps to do
so (it's low on my list).

in cvs. If you are unwilling/unable to compile these yourself please send
me or another jdbc developer an email and we'll make sure you've got the
right binaries. For now you could use http://www.ejurka.com/pgsql/jars/

That would be nice. I certainly want to provide up to date jars for people.
While I've got your attention on this, where is a good place for the RPM to
place the jars that would be usable by the largest number of people?
Currently they are just plunked down and no real installation is being done.

Or, to put it a different way, how would you want to see the RPM handle the
jars? There are significant issues to deal with, but give me your wish list.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu

On Fri, 19 Dec 2003, Lamar Owen wrote:

While I've got your attention on this, where is a good place for the RPM to
place the jars that would be usable by the largest number of people?
Currently they are just plunked down and no real installation is being done.

Or, to put it a different way, how would you want to see the RPM handle the
jars? There are significant issues to deal with, but give me your wish list.

I'm the wrong person to ask about RPMs a debian fan, but I don't think you
can do much better than just putting them somewhere. There are four
different jar files each for a different java runtime environment, so
you'd need to somehow figure out which version they want. Even if you
figured out which version they were using, deciding where to put it is
another difficulty. Classloading in java can be a real rats nest. Just
putting it in a standard location (Debian uses /usr/share/java for all
jars) is fine so other people/packages can adjust their classpath to use
it or symlink it to another location.

Kris Jurka

Guys

I have to agree wirh Kris, the set of rpms for RedHat 9 implies that it is a
consistent release for 7.4. However the postgresql-jdbc rpm contains two
sets of jar files and NO documentation, so it is a matter of guess work as
to what files are the ones to use. This is a shame as it undermines what is
otherwise a superb application. On the subject of docuemntation the Javadocs
for the jdbc drives would be really welcome.

regards

Lewis

Guys

As a user of your software I'm not too concerned about where the jars are
located, what I do need is clear documentation. This is the one area in
which Postgresql could do with improvement. Ideally I'd like to see this on
the web site and duplicated in the rpm files. Really basic things such as
where files are located and which jar file to use in order to achieve
certain goals. With this information anybody who is capable of installing
Postgresql should be capable of modifying the classpath as well.

regards

Lewis