Re: sqlite locking and svn client concurrency

Johan Corveleyn <jcorvel_at_gmail.com> writes:

> - This 10 second timeout, for a read operation that is blocked by some
> write transaction: is this implemented somewhere in the svn source
> code (if so, where?), or is this some configuration setting for the
> sqlite connection or something like that?

It's hard-coded, see BUSY_TIMEOUT in subversion/libsvn_subr/sqlite.c

> - If a read operation (with a "shared lock" I presume) squeezes in
> between write transactions of a large write operation, and that read
> takes a long time, I suppose the next write transaction of that large
> operation will also block, with the same timeout?

Yes, I think so.

> - Does this also work for two writers? Or do they block out each other
> with the working copy lock (wc_locks table)?

The wc locks will exclude multiple writers providing all writers take a
wc lock but I don't know whether all writers do that. I suppose we
could add some code to check.

> - With your remark about the workqueue making the read fail, is this
> how a read operation may proceed?
> * Try to get a shared sqlite lock for reading. Block for max. 10s if
> the db is locked for writing (error out if timed out).
> * When db reading is allowed (shared lock acquired), first read the
> work_queue. If it's not empty: error out.
> * Finally, read what we want to read, and get out.

Yes.

> (and the above sequence may be part of a larger read operation that
> e.g. does a query per directory, so this sequence may be repeated
> several times, perhaps interleaved with some large write operation
> that intermittently takes a write lock for things done per directory
> or somesuch)
>
> - All things considered, the "old" non-exclusive mode sounds quite
> non-deterministic. I mean, isn't this very hard for large GUI clients,
> IDE plugins, ... to handle this?

Probably, but I've not written any so I don't know.

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