Thanks for this response and the previous one. Much knowledge being gained!
Brett -----Original Message----- From: Knut Anders Hatlen [mailto:[email protected]] Sent: Thursday, March 01, 2012 4:44 PM To: [email protected] Subject: Re: Another question regarding memory and queries not using prepared statements "Bergquist, Brett" <[email protected]> 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
