On 07.09.2010 14:29, Matthew Bentham wrote: > On 07/09/2010 13:02, Bert Huijben wrote: >> >> >>> -----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). > > 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