On Fri, 9 Jun 2006, Pat Wibbeler wrote:
I'm curious - how does this avoid the buggy NFS fcntl() problem
mentioned under FAQ 7?
http://www.sqlite.org/faq.html
Does it use an external locking mechanism?
sortof. basically rq setups a directory like this
q/db
q/lock
q/...
here the 'lock' file is a file that is locked using fcntl __before__ any
transaction is started on the sqlite db. so it applies a write lock for write
transactions and read lock for read transactions.
if, during the transaction, an sqlite locking error is throw something has
gone drastically wrong and a 'recovery' is attemted under the an nfs safe
lockfile class. this entails doing some inode stuff, sqlite vaccum - etc.
this should never happen and i've seen it only once in two years of 24x7 rq
use on our 30 node cluster.
rq makes a few optimizations - for instance read transactions are attempted
'blind' - rq simply tries without a lock and, if a locking error is thrown,
only then aquires a read lock. even with a busy queue this means most reads
do not bother to lock the external file - though sqlite obviously performs
it's own locking.
basically the whole thing it to guard against two simoultaneous writers - they
are in effect always serialized. in fact, i do a lot of work over NFS with
sqlite using this approach - so long as you can prevent multiple writers it's
safe - at least using linux NFS - i've had bad luck with solaris.
the approach has been much more robust that i anticipated : we've been through
disk failures and power outages and never has the db become corrupt. no users
have reported a db corruption either.
sqlite is a very nice peice of coding!
cheers.
-a
--
suffering increases your inner strength. also, the wishing for suffering
makes the suffering disappear.
- h.h. the 14th dali lama
