[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Thu, 18 Oct 2012 18:04:59 +0100 (BST)

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

This is an archived mail posted to the Subversion Dev mailing list.