On Mar 8, 2006, at 8:35 AM, Christian Smith wrote:
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?
Mac OSX has supported all of the locking mechanisms listed above. Yes.
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.
This raises an issue that hasn't been resolved cleanly, if all of the
clients of the database file aren't using the same locking style -
you're going to have problems. So, what's a good way to ensure that
database file clients don't get themselves into trouble? Ideally,
when you open a database you would need to check that the type of
locking you are preparing to use is compatible with other clients
locking and if you're the first one to open it, then somehow mark it
to indicate the locking style restrictions.
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.)
Choosing a locking scheme at open seems to avoid a number of
potential problems that could come up if you could change your
locking style willy-nilly. URIs also open up some other nice options
which might be interesting/useful.
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.
