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 ...
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2403661
Received on 2009-10-05 16:18:07 CEST