In case the designer knows that the DB file will be accessed by a single program-thread throught the run - then there should be some sort of flag indicating that SQLITE should execute minimum locking-related code.
We were facing problems with flock over NFS mounted file systems. Since we din't need any locking on our DB file I copy-pasted the return statement in function 'sqlite3OsLock' to the beginning of the function, so that it always returns SQLITE_OK. Regards, ritesh On Wed, 2006-03-08 at 05:36, Adam Swift wrote: > All, > > In order to provide locking support for database files mounted from > remote file systems (NFS, SMB, AFP, etc) as well as provide > compatible locking support between database clients both local and > remote, I would like to propose some additions to the existing > database file locking behavior. > > I have discussed this briefly with D. Richard Hipp and he has > expressed interest in pursuing it. We would appreciate feedback/ > suggestions/concerns on the proposed solutions below. > > 1. Support a variety of locking mechanisms, from the lowest > granularity (using a <database_name>.lock file) to the highest (the > existing advisory locks). A preliminary list: .lock files, flock, > afp locks, posix advisory locks. > > 2. Allow clients to specify type of locking (on database open) > manually or ask sqlite to automatically detect the best locking > supported by the file system hosting the database file (automatic > detection would not work in a mixed local/remote file system > situation, all clients of a single database file need to use the same > type of locking to avoid conflicts). > > 3. Extend the sqlite3_open commands to support URI style path > references in order to specify the file system locking type (as > opposed to modifying the arguments list). After a little poking > around on RFC 3986 <http://www.ietf.org/rfc/rfc3986.txt> I'm inclined > to specify the locking choice via the query part of the URI. For > example: > > file:///mounts/myhost/dbfile.db?locktype=flock > file:///localdisk/otherdbfile.db?locktype=automatic > > Thanks in advance for your input. > > Adam Swift >
