Re: JDBC broken connection against Postgres 8.4
От | Michael Bell |
---|---|
Тема | Re: JDBC broken connection against Postgres 8.4 |
Дата | |
Msg-id | 186151.74695.qm@web43145.mail.sp1.yahoo.com обсуждение исходный текст |
Ответ на | Re: JDBC broken connection against Postgres 8.4 (dmp <danap@ttc-cmc.net>) |
Ответы |
Re: JDBC broken connection against Postgres 8.4
|
Список | 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 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
В списке pgsql-jdbc по дате отправления: