Thread: Jdbc connection pooling and PG 7.4 consistently fails
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? regards Lewis Lewis Foti e: lewis.foti@mentation.com m: +44 (0)7771 535943 w: www.mentation.com
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 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 > -----Original Message----- > From: Kris Jurka [mailto:books@ejurka.com] > Sent: 19 December 2003 22:10 > To: Lamar Owen > Cc: Lewis Foti; pgsql-bugs@postgresql.org; pgsql-jdbc@postgresql.org > Subject: Re: [BUGS] Jdbc connection pooling and PG 7.4 consistently > fails > > > > > 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 > -----Original Message----- > From: Kris Jurka [mailto:books@ejurka.com] > Sent: 19 December 2003 21:11 > To: Lamar Owen > Cc: Lewis Foti; pgsql-bugs@postgresql.org > Subject: Re: [BUGS] Jdbc connection pooling and PG 7.4 consistently > fails > > > > > 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 > >