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.
>> 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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2403597
Received on 2009-10-05 15:34:14 CEST