> -----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).
I can't tell you why obtaining just a shared read lock is faster than
obtaining an exclusive write lock, but the performance numbers are clear.
The only reason I can come up with is that it has to verify if it still has
the lock every now and then (not documented as far as I can tell, but would
be the sensible thing to do, to guarantee stability). And that could be more
expensive for an exclusive write lock.
Bert
>
> Matthew
Received on 2010-09-07 14:06:23 CEST