db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bergquist, Brett" <BBergqu...@canoga.com>
Subject RE: Another question regarding memory and queries not using prepared statements
Date Thu, 01 Mar 2012 21:52:13 GMT
Thanks for this response and the previous one.  Much knowledge being gained!

Brett

-----Original Message-----
From: Knut Anders Hatlen [mailto:knut.hatlen@oracle.com] 
Sent: Thursday, March 01, 2012 4:44 PM
To: derby-dev@db.apache.org
Subject: Re: Another question regarding memory and queries not using prepared statements

"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



Mime
View raw message