Whenever this topic has come up (which isn't very often) I've suggested
that people try tying the hash that CachedKids is a reference to.
Here's a slide from 2002 :-)
http://search.cpan.org/src/TIMB/DBI_AdvancedTalk_2002/sld032.htm
Could you try out that approach? (I don't think anyone has yet.)
It has the added advantage of not adding any cost for people who don't
need it.
Tim.
On Wed, Oct 11, 2006 at 12:47:15PM -0500, Brandon Black wrote:
> Attached is a rough draft patch against the DBI trunk for some rudimentary
> sth cache management, to help with the issues when the sth cache grows
> indefinitely for a long-running process. We had some discussion on the
> DBIx::Class IRC channel about needing this functionality, and it started
> sounding like a better idea to implement this in DBI itself rather than
> privately in our DBIx::Class::Storage::DBI layer, since this is a general
> problem that non-DBIx::Class-users face as well.
>
> Basically, it adds a dbh method "manage_sth_cache", which when invoked does
> some max_age and lru magic to prune the cache. The max age and max #
> statements are dbh object attributes that can be tuned. It also adds a
> Created attribute to sth's, which stores the value of "time" when they are
> created. Then there's another dbh attribute which, if set, allows
> prepare_cached to periodically invoke manage_sth_cache for you at a certain
> minimum time interval (say at most every 5 minutes, or whatever interval the
> user decides).
>
> Feedback on whether something of this nature should or shouldn't be in DBI
> itself, or how it should be implemented, welcome. I don't really know what
> I'm doing with the DBI source anyways. I suspect that the attributes added
> in this patch should be CamelCase instead of dbi_foo like I have them now
> (?), but it was much simpler to use dbi_foo for a draft patch, since it
> didn't involve mucking with C structs and the FETCH magic and such directly.
>
> -- Brandon
