[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 14:42:57 +0300

Philip Martin wrote on Mon, Jun 20, 2011 at 12:01:44 +0100:
> Philip Martin <philip.martin_at_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
Received on 2011-06-20 13:43:54 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.