Johan Corveleyn <jcor...@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
