[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

SQLite locking and FSFS rep-sharing

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Fri, 17 Jun 2011 11:06:11 +0100

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

Start with a new repository and use gdb to interrupt the post-commit:

  $ gdb -arg svn import -mm Makefile file://`pwd`/repo/f1
  (gdb) b write_reps_to_cache
  (gdb) r
  Breakpoint 1
  (gdb) fin

That runs to the end of write_reps_to_cache so the process has written
to the database but not released the lock. Then in another terminal run:

  $ svn import -mm Makefile file://`pwd`/repo/f2
  Adding Makefile

  Committed revision 2.

  Warning: post commit FS processing had error:
  database is locked

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?

Received on 2011-06-17 12:06:50 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.