Re: svn commit: r1398389 - in /subversion/trunk/subversion: include/ libsvn_client/ libsvn_subr/ libsvn_wc/ svn/ tests/libsvn_wc/

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.

-- 
Join us this October at Subversion Live 2012
http://www.wandisco.com/svn-live-2012