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

RE: Any FSFS rep-sharing experts out there?

From: Bert Huijben <rhuijben_at_sharpsvn.net>
Date: Mon, 5 Oct 2009 15:18:34 +0200

> -----Original Message-----
> From: Mark Phippard [mailto:markphip_at_gmail.com]
> Sent: maandag 5 oktober 2009 15:02
> To: Branko Cibej
> Cc: dev_at_subversion.tigris.org
> Subject: Re: Any FSFS rep-sharing experts out there?
> On Mon, Oct 5, 2009 at 6:57 AM, Branko Cibej <brane_at_xbc.nu> wrote:
> > If so, please help me figure out how to figure out ´╗┐issue #3506.
> From my reading, SQLite locks the entire database file when it is
> writing. So if the large commit is writing a lot of data to the file
> it could be that the lock window is high. I imagine it is also
> possible for the size of the database in the ASF repository to make it
> take even longer?

Normally SQLite doesn't block the entire database, but just the tables it will be writing to when committing the current transaction.

The documentation also says something about: If the changes are too large to fit in the memory cache, the lock is promoted to a full exclusive lock to allow spilling intermediate results to the database file.

This last thing might be the case here....?

> Are we using these features of SQLite?

I don't think we install a busy handler, and I don't know if we want to enable this globally; probably not.

In the WC-Layer I would prefer an immediate negative answer over a delay..

Retrying is in most cases not a valid answer to this. Just look at the WIN32 retry loop, which is/was sometimes used on multiple levels.. which could make directory deletes take a half minute when there was a locked file where the code assumed a directory.

But maybe we should enable this for this specific repository use of SQLite.


> http://www.sqlite.org/c3ref/busy_handler.html
> It seems like our code needs to wait for the lock to clear, at least
> for a little bit of time. Of course we also need to do as much as we
> can to have the lock window be as small as possible.
> It seems like this will be a potential WC-NG issue as well if you have
> multiple processes accessing the same WC.
> --
> Thanks
> Mark Phippard
> http://markphip.blogspot.com/
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageI
> d=2403570

Received on 2009-10-05 15:20:34 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.