Philip Martin wrote on Mon, Jun 20, 2011 at 15:51:11 +0100: > Daniel Shahaf <danie...@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. >
I'm not surprised. By the time write_reps_to_cache() has finished, the INSERT stmt had been run and reset already, so as far as sqlite is concerned there are no writers around. > -- > Philip
