All, Please ignore my previous e-mails as I have found where my problem lies and it is not in the Postgresql driver. Apparently Enhydra uses a prepared statement cache and the size of my prepared statements and the number of statements being allowed into the cache (was at 256. I tuned it back to 64) was contributing to the OutOfMemoryError. Barry - Thanks so much for recommending OptimizeIt. It was key to finding my problem. To all who are working on this project and have helped give my some clues, many thanks. I have been using Postgresql for a while now and am extremely happy with it. Thanks again. John John Cook wrote: > 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 [EMAIL PROTECTED] > > > > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly