On 07.09.2010 14:29, Matthew Bentham wrote:
> On 07/09/2010 13:02, Bert Huijben wrote:
>>
>>
>>> -----Original Message-----
>>> From: Matthew Bentham [mailto:mjb67_at_artvps.com]
>>> Sent: dinsdag 7 september 2010 13:48
>>> To: Bert Huijben
>>> Cc: 'Justin Erenkrantz'; 'Greg Stein'; 'Johan Corveleyn'; 'Subversion
>>> Development'
>>> Subject: Re: Worried about single-db performance
>>
>>
>>> I didn't realise this, you are of course right that that would make it
>>> unacceptable. I don't really understand why it would break
>>> TortoiseSVN,
>>> does it take write access and then not release it somehow?
>>
>> SQLite needs a shared *read* lock to *read*. See
>> http://www.sqlite.org/atomiccommit.html.
>> (Invoking 'svn status' never obtains a write lock; see that document)
>>
>> SQLite only upgrades that read lock to a write (or actually reserved)
>> lock
>> when you perform a db operation that has to change the database.
>> Further on
>> (E.g. too many changes, but look at the documentation for more
>> reasons) this
>> is upgraded to an exclusive lock that blocks all readers and writers
>> out of
>> the db, but it tries to keep this time as short as possible.
>>
>> Your original suggestion is just to make any *reader* block any other
>> *reader*. Which breaks the subversion world. (Just running svn update
>> in 1.6
>> has about 5 simultaneous independent readers in some phases of
>> update. Most
>> GUI subversion clients I know use multiple client instances at the same
>> time, so they would all have to be rewritten if we obtain an
>> exclusive lock
>> for reading).
>
> Sorry, I didn't mean we should take exclusive locks for every
> transaction, just that we should use "PRAGMA locking_mode=EXCLUSIVE".
> According to the documentation (http://www.sqlite.org/pragma.html)
> that makes transactions obtain a shared lock for reading which is
> upgraded to an exclusive lock for writing, and not released until the
> database connection is closed. I've tried it a couple of times in
> svn.exe and it always improves performance (over locking_mode=NORMAL)
> and hasn't caused me problems. Admittedly I haven't tried within the
> last couple of weeks and I'm afraid I don't have time right now.
>
> Am I misreading the documentation? It says "The first time the
> database is read in EXCLUSIVE mode, a shared lock is obtained and
> held. The first time the database is written, an exclusive lock is
> obtained and held".
That "and held" is the problem, IMO. A long-term connection that mostly
reads but just happens to write something once will not drop the
exclusive lock "until the database connection is closed".
-- Brane
Received on 2010-09-07 17:31:15 CEST