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

Re: SQLite locking and FSFS rep-sharing

From: Daniel Shahaf <danielsh_at_elego.de>
Date: Mon, 20 Jun 2011 18:54:51 +0300

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

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
Received on 2011-06-20 17:58:42 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.