Re: JDBC broken connection against Postgres 8.4

>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
hadthe 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.close();
               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
connectionspaired 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
connectionobject. (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
furtherin 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(DerbyConnectionPool.java:193)

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

*warning: boring and unedifying explanation: I had a static method called getCon() to call to get the unpooled
connectionin 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
someonewondering if I was using the cpool :) 

danap