On Tue, 7 Mar 2006, 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.
Would be useful, especially for the Mozilla work. > >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. Why not start with just .lock and the existing locks? MacOS provides posix advisory locks, I assume? > >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). So long as the better locking recognises the more primitive .lock files, this should be workable. The use of .lock files is easy to test for at database open time. > >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 I'd be more inclined to add a PRAGMA. URIs are ugly and a pain to type in, epsecially if you're lazy and rely on filename completion. Of course, I assume the non-URI form would still work, but a PRAGMA still makes more sense to me (and can be queried without parsing the URI.) Perhaps multiple .lock files could be used to implement read/write locks. Locks files of the form "<database>.rd.lock.<id>" would be individual read locks, which would be all hard links to the same "<database>.rd.lock" file, and the file reference count would be the read lock count. A reserved lock would be indicated by the presence of both the "<database>.rd.lock" and "<database>.wr.lock" files, and once the last reader has finished, the "<database>.rd.lock" file is removed and the lock is promoted to exclusive. Such use of read/write lock files might slow the library down, though, as directory operations are generally synchronous. > >Thanks in advance for your input. > >Adam Swift > Christian -- /"\ \ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL X - AGAINST MS ATTACHMENTS / \
