> -----Original Message----- > From: Matthew Bentham [mailto:mj...@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
