[Dbix-class] memory leak - found

[Matt S Trout]

Brandon Black wrote:
  > It would be nice if DBI and/or Postgres (postgres is involved in this
> as well, since ->prepare_cached on recent postgres caches the prepped
> statement server-side) had an option to limit the total number of
> cached/prepared statements to X based on LRU (or even better, based on
> least savings in terms of how often the sth is used * the prep costs
> it saved), but that's pie in the sky for now.  In the meantime I just
> have my daemons disconnect and reconnect to the db every so often to
> flush it all out.  It might be even smarter to have them do their own
> smart sth reaping on $dbh->{CachedKids}.

That would be *very* cool. Might be easier to just cache prepared handles 
ourselves though so that we can manage whether a cursor has it or not - the 
current approach of having Cursor call back to Storage::DBI every time it 
needs to execute a $sth (since prepare_cached will recycle any sth that isn't 
->{Active}).

> It's not as much of an issue with "normal" DBIC usage, as the
> statements should map at worst 1:1 with the various DBIC method calls
> you see in your app source code, which are finite.

Hmm. Except if searches are being built from user criteria it can be a very 
large finite over the life of a process. I wonder if we should have some sort 
of cache threshold - i.e. any given Storage::DBI instance doesn't cache a 
query at all until it's seen it N times, with a configurable value of N.

-- 
      Matt S Trout       Offering custom development, consultancy and support
   Technical Director    contracts for Catalyst, DBIx::Class and BAST. Contact
Shadowcat Systems Ltd.  mst (at) shadowcatsystems.co.uk for more information

+ Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +