This would be worth following up in the NFS case, or if I get around to configuring the clustering filesystem with a userspace personality that understands posix locks, but I don't think it has much impact on the flock() call, judging by the comments in the code: ```` ************************** Begin flock Locking ******************************** ** ** Use the flock() system call to do file locking. ** ** flock() locking is like dot-file locking in that the various ** fine-grain locking levels supported by SQLite are collapsed into ** a single exclusive lock. In other words, SHARED, RESERVED, and ** PENDING locks are the same thing as an EXCLUSIVE lock. SQLite ** still works when you do this, but concurrency is reduced since ** only a single process can be reading the database at a time. ```` I had to [patch](http://sqlite.1065341.n5.nabble.com/sqlite-users-DSQLITE-ENABLE-LOCKING-STYLE-1-doesn-t-work-on-Linux-Cygwin-td70789.html) the sqlite code to get flock() to work at all under Linux, but once enabled it did make the critical difference (crashing programs now worked). I'm not personally too concerned with the locking style in use, as long as it's functional and correct. The queries in use are highly unlikely to be time-consuming, so taking an EXCLUSIVE lock (while reducing concurrency) is likely to be massively outweighed by other processing and network costs in the system as a whole. Actually, since you mention the bug, I just checked my SQLite amalgamation version number, and it's 3.31.0 so - It's possible the flock() call has been patched properly, in which case disregard the above patch comments - I would apparently be vulnerable to that bug you mention (gulp: COMMIT not committing...). - It seems it's more than past the time to re-do that amalgamation...