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

Re: Merge tracking: will SQLite make NFS sad?

From: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2007-03-05 19:06:27 CET

On Mon, Mar 05, 2007 at 12:34:06PM -0500, Daniel Berlin wrote:
> >In my (albeit limited) experience of SQLite, it doesn't seem to attempt a
> >great deal of concurrency (until recently, you could deadlock by deleting
> >rows that you were currently iterating through with a SELECT).
> They don't recommend it mainly for the same reasons nobody recommends
> doing anything that requires locking over NFS:
> Too many buggy locking implementations.
> If you actually take a look at what sqlite does code wise, it requires
> that exactly the same lock mechanisms work that we require work for
> FSFS, so we're fine if FSFS would work.

Well, it's not quite the same. FSFS only requires that whole-file
advisory locking works, while SQLite seems to require 'proper' byte
range locking. I don't know if there's a difference in the quality of
client implementations in practice.

I'm also interested to know what SQLite's concurrency is like: do we
have to do anything special to ensure that multiple readers (on different
threads, processes, machines) can co-exist happily with writers?

(By the way, don't take this as a dig at SQLite at all - I think it's
great, and I use it myself for single-user applications, but I don't
know what the characteristics are for multi-user or shared filesystem


  • application/pgp-signature attachment: stored
Received on Mon Mar 5 19:06:53 2007

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.