[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: Branko Cibej <brane_at_xbc.nu>
Date: Mon, 05 Oct 2009 16:17:50 +0200

Mark Phippard wrote:
> 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
> regardless.

There's a single database with single table, yes. According to Paul's
report, this only happens for large commits -- so it would appear that
we should either try to write the rep-sharing info in smaller chunks, or
-- more likely, given that it's probably due to on underlying buffer
flush in SQLite -- trap the SQLITE_BUSY signals (possibly in fs_open?).

Though as Bert says, that last could lead to strange delays in opening
FS connections.

-- Brane

P.S.: Or use BDB instead of SQLite ...

Received on 2009-10-05 16:18:07 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.