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
access).
Regards,
Malcolm
- application/pgp-signature attachment: stored
Received on Mon Mar 5 19:06:53 2007