On Thu, May 28, 2015 at 03:59:51PM +1200, Duncan McEwan wrote: > On Tue, 26 May 2015 14:13:05 +0100 Tim Bunce <tim.bu...@pobox.com> wrote: > > > I've added this as a note: > > > > Note that the ChildHandles array holds weak references and that 'from > > time to time' the old slots get freed up. This isn't a leak, it just > > appears to be if you're not familiar with the caching that DBI does > > internally. You can rest assured that if the DBI did have a real leak > > a) a great many people would be affected and b) it would get fixed very > > quickly. > > > > I think 'from time to time' is every 120 or so newly created child handles.
> But seeing this response from Tim about the fact that the DBI can cache up to > 120 or so handles made me wonder if this is true for database handles as well > as statement handles? Is it possible that our "problem" was simply the > correctly working DBI caching misbehaving due to our application running > persistently in multiple fcgid processes. Short answer: no. When a new handle is created the DBI simply pushes a weak reference to the handle onto the end of the ChildHandles array. Because it's a weak reference it doesn't interfere with the handle getting destroyed when the last (non weak) reference is removed. When the handle is destroyed, the corresponding element in the ChildHandles array is set to undef by the weak reference mechanism deep in the perl internals. The DBI isn't involved in that. The apparent 'leak' is because the element in the array still exists, albeit as an undef. The DBI clears out the undef elements occasionally to prevent the array growing indefinitely. Tim.
