db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <knut.hat...@oracle.com>
Subject Re: Another question regarding memory and queries not using prepared statements
Date Thu, 01 Mar 2012 21:44:24 GMT
"Bergquist, Brett" <BBergquist@canoga.com> writes:

> Looking at two heap dumps, one for yesterday and one for today, about
> 17 hours apart.  I notice that there is an increase in the
> classloaders of about 1150.    Somewhere I think I remember that
> derby creates classes on the fly for queries and loads them.  Is this
> true?

Yes. And there will be a separate classloader instance for each
generated class.

> Related to the question is that I have a query that is created as a
> Statement, not a PreparedStatement.   I am not using a
> PreparedStatement as the tables involved in the query are dynamic.  
> A unique query is run about 4 times an hour.   Is this going to cause
> memory problems, permgen space in particular?

It shouldn't cause such problems. The query will stay in memory for a
while after completion, but it should be eligible for garbage collection
once it's no longer in the statement cache. The statement cache holds
100 statements by default, so the permgen footprint should be bounded.

> I could change the query to use a PeparedStatement but at the time I
> did not see any benefit as the query is going to be used exactly
> once.

The resource usage should be the same when you execute a
PreparedStatement once, so I don't think there's much benefit in
switching from Statement.

Knut Anders

View raw message