Re: Memory Leak / Prepared Statement - Mailing list pgsql-jdbc
From | John Cook |
---|---|
Subject | Re: Memory Leak / Prepared Statement |
Date | |
Msg-id | 3B6AFFC8.1F957B05@interport.net Whole thread Raw |
In response to | Memory Leak / Prepared Statement (John Cook <johncook@interport.net>) |
Responses |
Re: Re: Memory Leak / Prepared Statement
RE: Re: Memory Leak / Prepared Statement |
List | pgsql-jdbc |
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 > > > >
pgsql-jdbc by date: