On Wed, Oct 19, 2011 at 4:16 PM, Jay A. Kreibich <j...@kreibi.ch> wrote: > On Wed, Oct 19, 2011 at 03:24:35PM -0500, Nico Williams scratched on the wall: >> Also, regarding NFS, it would be safe to use if SQLite3 were to use >> whole-file byte range locks. NFS makes concurrent access to byte >> ranges that are not locked unsafe. Of course, safely making changes >> to how SQLite3 locks files may be difficult now... >> >> CIFS does support byte range locking, and I suspect that the same rule >> I mentioned above regarding NFS applies. Plus, as a last resort >> there's CIFS open deny modes that SQLite3 could use to prevent >> concurrency. > > Just because the standards include such features, you seem to be > under the impression that every client and every server running on > top of any filesystem actually implement said features correctly, > and that every combination of client and server interacts and > operates correctly.
I assume that? I'm aware that the Linux NFS client did not support distributed byte range locking prior to kernerl 2.6.12. That doesn't mean that SQLite3 couldn't have an option to do locking in a way that would work with NFS -- it just means that it'd be unsafe to use SQLite3 on NFS on older Linux distros with any concurrency, that the application would need additional locking (like, e.g., Firefox does or used to). > As for modifying SQLite, the locking mechanism is actually somewhat > modular, and I believe SQLite already includes the ability to some > types of range locks. That still doesn't do you any good if the > filesystem doesn't answer the APIs correctly. True, but one would have to make sure that older releases of SQLite3 don't open a DB that uses a lock protocol that they don't support. That can be done by, e.g., having a different magic, but I think we'd all want the new thing to NOT be the default. Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
