Re: Memory Leak / Prepared Statement
От | John Cook |
---|---|
Тема | Re: Memory Leak / Prepared Statement |
Дата | |
Msg-id | 3B6A311B.540B6DB@interport.net обсуждение исходный текст |
Ответ на | Memory Leak / Prepared Statement (John Cook <johncook@interport.net>) |
Список | pgsql-jdbc |
Barry, You are right on 2 points. First, LIKE is not the issue, as I modified the code to remove it, but still have the same problem. Also, 1.4 didn't have any impact either. I have done my best to go through my code with a fine tooth comb, but I will do it again. I will test the code an submit it to the group. Thanks for the help. 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 по дате отправления: