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
>
>