Philip Martin wrote on Mon, Jun 20, 2011 at 12:01:44 +0100: > Philip Martin <philip.mar...@wandisco.com> writes: > > > The second commit doesn't wait for the 10 second SQLite busy timeout, it > > gives the 'database is locked' error immediately. > > > > Should we be doing more to support concurrent writes here? An explicit > > loop in the post-commit? A different SQLite configuration? > > A change from 1.6 is that 1.7 uses sqlite for packed revprops. It turns > out that the packed revprop database doesn't have this problem because > access to it is protected by the FSFS repository lock. >
Another difference: failed access to revprops.db should be treated as an error condition, failed access to rep-cache.db should be reported as "Commit succeeded but post-commit FS processing failed". > We could change the rep-sharing database access to take the FSFS > repository lock. Read access to the database already occurs at a point > when the lock is held. > 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. > -- > Philip
