[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Mergeinfo.db file kept open by apache after sql error

From: Lieven Govaerts <svnlgo_at_mobsol.be>
Date: 2007-08-28 13:39:05 CEST

Quoting Daniel Rall <dlr@finemaltcoding.com>:

>
> On Aug 26, 2007, at 1:05 AM, Lieven Govaerts wrote:
..
> > In mergeinfo-sqlite-index.c/svn_fs_mergeinfo__get_mergeinfo(), but
> > also
> > in svn_fs_mergeinfo__update_index and
> > svn_fs_mergeinfo__get_mergeinfo_for_tree the call to sqlite3_close is
> > not in the 'finally' path (in java terms), so whenever there's an
> > error
> > accessing the database it's not closed correctly.
> >
> > Does this make sense?
>
> Thanks for the report, Lieven. I've added some simple error handling
> improvements in r26340 which fix this problem.

That should do it. One small remark: What do you think of renaming the
MAYBE_CLEANUP macro to CLEANUP_ON_ERROR, extending it
to take the 'err' variable as parameter and move to a
common include file so we can use it throughout whole the code? I've found
hundreds of instances where we use this pattern, might as well make it more
standard.

> I was wondering, though -- should we also attach the same sort of
> connection cleanup code to a pool cleanup function? Or would that be
> needless additional complexity?

As far as I see in the code we open & close the db connection in the scope of
one function, there's no handover of ownership involved. I don't think there's
much value to registering a cleanup function right now, if we're sure we handle
all return paths correctly.

Lieven

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 28 13:36:22 2007

This is an archived mail posted to the Subversion Dev mailing list.