RE: Re: Memory Leak / Prepared Statement - Mailing list pgsql-jdbc
From | Dave Cramer |
---|---|
Subject | RE: Re: Memory Leak / Prepared Statement |
Date | |
Msg-id | 008201c11c54$5d7fed20$8201a8c0@inspiron Whole thread Raw |
In response to | Re: Memory Leak / Prepared Statement (John Cook <johncook@interport.net>) |
List | pgsql-jdbc |
John, Please pick the driver up from http://jdbc.fastcrypt.com This has been built from the most recent cvs Dave -----Original Message----- From: pgsql-jdbc-owner@postgresql.org [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of John Cook Sent: August 3, 2001 3:47 PM To: Barry Lind Cc: pgsql-jdbc@postgresql.org Subject: [JDBC] Re: Memory Leak / Prepared Statement Barry, I got OptimizeIt configured, and it looks like it is jdbc2/PreparedStatement which is not being garbage collected. All of my PreparedStatement s stay visible in Optimize it and the number of instances never decreases. What other information can I provide to help determine if this is a memory leak or another problem? I am using Postgresql 7.1.2 and the driver that accompanied it. Thanks. John Barry Lind wrote: > My guess is that this is unlikely to be the result of the ThreadLocal > issues and also I doubt 1.4 will have any effect. This sounds like a > memory leak which could be in the driver or in your application code. > I also doubt that the use of LIKE is the problem as the JDBC code > doesn't parse the SQL so it doesn't know if you are using LIKE or not. > > To fix this we would either need a reproducable test case that you > could submit such that we could reproduce the problem and fix it, or > you could use a java memory profiler to track down what objects are > being allocated and not released. I personally like OptimizeIt as it > has helped me solve quite a few memory leak problems with java code. > > thanks, > --Barry > > John Cook wrote: > > > Hi, > > > > I noticed several postings a month ago regarding a memory leak > > brought about by the use of Thread.Local in > > jdbc2/PreparedStatement.java. I have what seems like a similar > > problem, but I am not sure. I have applied the patch, but I still > > have my problem (mine is not really associated with DateFormat > > usage.) > > > > I am running Enhydra Application Server 3.1 on top of Postgres and I > > have been running an application that tries to match text strings to > > items in my database. It has been running fine for months until I > > recently made a modification that uses a lot of "LIKE" statements > > (i.e. anywhere from 2-200 at a time.) Performance is fine, but > > memory starts getting eaten up and I eventually hits an > > OutOfMemoryError. The bigger the prepared statement (i.e. the more > > LIKEs) the more memory is eaten and the faster I run out of memory. > > Oddly enough, before I added the LIKE statements, I was running fine > > and, although I used a lot of prepared statements (the app server > > did), memory was not being eaten like this. > > > > Has anyone had a similar experience and is it related to the > > Thread.Local problem? Does anyone know if this is addressed in the > > 1.4.0 beta JDK or is it scheduled to be addressed in an upcoming > > Postgresql release? > > > > Any help would be greatly appreciated. > > > > Thanks in advance. > > > > John Cook > > > > > > > > > > ---------------------------(end of > > broadcast)--------------------------- > > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > > > > ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly
pgsql-jdbc by date: