Skip site navigation (1) Skip section navigation (2)

Re: JDBC broken connection against Postgres 8.4

From: Michael Bell <mikebell90(at)yahoo(dot)com>
To: dmp <danap(at)ttc-cmc(dot)net>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: JDBC broken connection against Postgres 8.4
Date: 2009-08-19 04:32:36
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc

>I'm still unable to reproduce the exception on the given configuration when the JDBC has
>been upgraded to postgresql-8.4-701.jdbc3. I will upgrade to PostgreSQL 8.4 tomorrow,
>been meaning to, on one of the systems and try again. I realize you are talking about 8.4
>and what I was trying to do is provide an elimination of one or more variables to isolate
>the problem, so the experts here could focus, which I believe they may have already done. I
>also understand that mine are Linux and your is windows and you believe there lies the possible
>whack so to speak. Couple of things though:

Yup.. Thanks. I tried both the 8.3 and 8.4 jdbc but only against 8.4. Note that a post in Feb DID go against 8.3 and he had the same issue (search archives for connection: reset)

1. The original test code you provided I believe is not doing exactly what you think. con is never
    NULL besides the first time through the loop, which the test to close the connection is taking
   place no matter whether a connection was established or not. You always close the connection,
   Suggest you try:

   } finally {
           if (con != null)
               con = null;

   I know this is probably be nothing, but your code is just not doing what you set it up to do.

Actually it is deliberately that way. I am deliberately creating a new connection and closing in a loop. (eg 250 new connections paired by closes) Am I being spacy and missing something? :)
Otherwise you would be creating a new Connection and relying on garbage collection to clean up the old deferenced connection object. (admittedly this matters not for this dumb test loop)

Also note that the Thread.sleep(2) was originally Thread.sleep(5000). That still triggers the exception, maybe slightly further in the loop.
2. If you say your connection is not pooled, why in your original exception trace, quoted above, is:

-> at com.gwava.db.DerbyConnectionPool.main(

Laziness. That just happened to be the class where I wrote that method, for boring and unrelated reasons*. Ok, mostly just laziness. Note that I originally SAW this issue when running Postgres through Hibernate 3.3.1, using C3P0 .9.1.2. I then said "well hey I'll eliminate Hibernate and the Connection pool as variables and just use raw JDBC to clean it up to that.

*warning: boring and unedifying explanation: I had a static method called getCon() to call to get the unpooled connection in this class, so I used that. I then simplified the code to a single main method with no alien (well non jdk) methods to make it easier to post. Both had the same results. Ironically one of the reasons I did so was to avoid someone wondering if I was using the cpool :)



In response to


pgsql-jdbc by date

Next:From: Devrim GÜNDÜZDate: 2009-08-19 11:03:57
Subject: Re: Can't build 8.4-701 on Fedora
Previous:From: dmpDate: 2009-08-19 03:14:55
Subject: Re: JDBC broken connection against Postgres 8.4

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group