Would it be useful to copy this explanation somewhere more discoverable -- somewhere in the source tree, or linked from the release notes page?
- Julian Philip Martin wrote: > Johan Corveleyn <jcor...@gmail.com> writes: > >> With this new "exclusive" mode it's probably quite clear (no >> parallellism possible at all), but because of the fuzzyness of the >> non-exclusive behavior this leaves me wondering: "which things does >> this exclusive mode make impossible, which were still possible under >> non-exclusive mode"? What does one lose by enabling exclusive mode? > > A write operation like "svn up" opens the working copy and then executes > a number of SQLite write transactions. SQLite will block other reads > while a write transaction is in progress. With shared, non-exclusive, > locking read operations can run between the write transactions. There > is a timeout (10s for Subversion) and while the whole write operation > may take a long time the individual write transactions are generally > shorter that the timeout. > > So from an SQLite perspective most read operations may run during a > write operation but may block before proceeding. From a Subversion > perspective the read operation will still fail to run if there is a > workqueue item. So in 1.7 read operations only work if they run between > write transactions when the workqueue is empty. > > With 1.8 exclusive locking the SQLite write lock is not dropped after > the first write transaction but it help until the whole write operation > is over and the database is closed. No read operations can run while > the SQLite write lock is held. >
