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 <jcorvel_at_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.
>
Received on 2012-10-18 19:05:38 CEST