Barry,
The PreparedStatement references were being held in a Hashtable cache inside
Enhydra. I was never actually using PreparedStatements directly, which was part
of what made finding the problem difficult.
For those who use Enhydra, there is a parameter called "maxPreparedStatements" in
the D
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 me
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 t
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
