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. -- Join us this October at Subversion Live 2012 http://www.wandisco.com/svn-live-2012
