Brian Smith wrote: > The statement quoted from the SQLite FAQ says that SQLite-NFS > problems are caused by NFS clients that do not implement > locking correctly. While that is definitely true, SQLite is > also to blame, because it uses fnctl locks in a way that is > incompatible with NFS locking/cache coherency semantics. > Section 9.3.2 of the NFSv4 specification [6] describes > SQLite's technique and the problem with it well:
I found some other problems with using SQLite over NFS. First, there is no hope for any kind of safety when NFSv4 or later is not being used. for earlier versions, NFS uses timestamps to detect modifications to files. However, NFS servers might not be able to keep time precisely enough for a client to detect two modifications that occur "close together". If the NFS server is Linux, for example, the odds are high that you will only be able to detect one modification per second. Also, NFS over UDP is a bad idea if you need reliability. The second problem is with sqlite3DetectLockingStyle. * When SQLITE_ENABLE_LOCKING_STYLE is set, different clients will end up using different types of locks based on their own configuration. For example, if client A doesn't have NFS locking set up correctly (e.g. statd or lockd is not running), it will use dotfile locking and ignore any fcntl-style locks. But, if client B has NFS locking set up correctly, it will use fcntl-style locks and ignore client A's dotfile lock. As a result, the database will become corrupted. If the NFS client daemons are start/stopped/restarted on a particular client, then this issue can occur even on a single client. * When client A is accessing the database from a read-write mount, it will use locking. But when client B is accessing the database from a read-only mount, it will not attempt any locking. Although client B will not corrupt the database, its view of the database file will be corrupted wheever client A writes to it. Accessing a SQLite database over a read-only mount is a bad idea if other systems (other clients or the server) is writing to the database file. * Windows uses a totally seperate locking mechanism and I will just assume that accessing a SQLite database over NFS is a bad idea. To solve these problem generally, a runtime option that overrides SQLITE_ENABLE_LOCKING_STYLE is needed, so that the application can always use the same locking style regardless of the client configuration, and regardless of the options with which SQLite was compiled. - Brian _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
