[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: Mark Phippard <markphip_at_gmail.com>
Date: Mon, 5 Oct 2009 09:34:02 -0400

On Mon, Oct 5, 2009 at 9:18 AM, Bert Huijben <bert_at_qqmail.nl> wrote:

>> 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....?

Some perhaps old stuff I read said the entire database is locked
during writing. In the case of rep-cache, isn't there only a single
table anyway? I have never looked but cannot imagine there are too
many tables. So a table lock would essentially lock everything

>> 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..

I was mainly thinking of the repos layer. We should not be
introducing problems like this into the repository. I do not even
think this feature should have been added to Subversion if it can
introduce problems like this.

Mark Phippard
Received on 2009-10-05 15:34:14 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.