Re: SQLite locking and FSFS rep-sharing

Daniel Shahaf <danielsh_at_elego.de> writes:

> Philip Martin wrote on Mon, Jun 20, 2011 at 12:01:44 +0100:
>
>> We could change the rep-sharing database access to take the FSFS
>> repository lock.

It probably makes more sense to use a separate rep-sharing lock.

> Hmm. Intuitively I wouldn't want sqlite writes to have to take the FSFS
> write lock, since I don't want to block commits on them.
>
> But. SQLite writers block readers, so as long as we write to
> rep-cache.db outside the FSFS write lock (with or without retries) we
> should ensure we don't start readers that hold the FSFS write lock.

Writers blocking readers doesn't seem to be a hard rule with current
SQLite. With one process stopped in gdb holding a rep-cache write lock
(after write_reps_to_cache has finished) another process can read the
rep-cache and get representations.

-- 
Philip