Hi.
You guys already distribute a SQLite version with locking support for
remote databases with Mac OSX.
What would be the difference to that mechanism?
To have this in the original SQLite would be great.
Best regards,
Manfred
Am 08.03.2006 um 11:06 schrieb Adam Swift:
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
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
