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
