Re: SQLite locking and FSFS rep-sharing

2011-06-20 Thread Daniel Shahaf
Philip Martin wrote on Mon, Jun 20, 2011 at 15:51:11 +0100: > Daniel Shahaf 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

Re: SQLite locking and FSFS rep-sharing

2011-06-20 Thread Philip Martin
Philip Martin writes: > The second commit doesn't wait for the 10 second SQLite busy timeout, it > gives the 'database is locked' error immediately. r1137660 changed the rep-cache update to optimise for the common case when the reps are not already present. It means that most of the time the up

Re: SQLite locking and FSFS rep-sharing

2011-06-20 Thread Philip Martin
Daniel Shahaf 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 hav

Re: SQLite locking and FSFS rep-sharing

2011-06-20 Thread Philip Martin
Daniel Shahaf 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. I was mistaken about this bit: >> Read access to the database already occurs at a point >> when the lock is held. Access

Re: SQLite locking and FSFS rep-sharing

2011-06-20 Thread Daniel Shahaf
Philip Martin wrote on Mon, Jun 20, 2011 at 12:01:44 +0100: > Philip Martin 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

Re: SQLite locking and FSFS rep-sharing

2011-06-20 Thread Mark Phippard
On Mon, Jun 20, 2011 at 7:01 AM, Philip Martin wrote: > Philip Martin 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

Re: SQLite locking and FSFS rep-sharing

2011-06-20 Thread Philip Martin
Philip Martin 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

SQLite locking and FSFS rep-sharing

2011-06-17 Thread Philip Martin
The FSFS rep-sharing database is an SQLite database updated post-commit. I thought that the SQLite busy timeout would handle concurrent updates from multiple commits but it doesn't work the way I expected. Start with a new repository and use gdb to interrupt the post-commit: $ gdb -arg svn imp