Adam Megacz <[EMAIL PROTECTED]> wrote: > I'm interested in using SQLite with AFS (the Andrew FileSystem). > Unlike NFS, AFS has solid, reliable support for *whole-file* advisory > locking across the network. > > AFS does some very sophisticated caching, so an SQLite database in AFS > accessed by a single reader/writer would be very efficient. A second > reader/writer would cause performance to degrade by breaking callbacks > quite often, but as long as whole-file locking is used, no corruption > should occur. > > I think a scenario where a database is accessed mostly by a single > process but occasionally updated by other clients (for example, for > administration) would work really well. In a lot of applications > (like the one I'm considering) this would eliminate the need for an > "administration API" implemented on the main reader/writer -- > administration could be done using the sqlite3 binary directly on the > database across AFS. > > I read through the locking code: > > http://www.srcdoc.com/sqlite_3.2.2/os__unix_8c-source.html#l00911 > > It looks like it would be possible to do the locking with whole-file > locks on three separate files (less elegant, certainly) rather than > byte range locks if one gave up support for old versions of Windows. > > Does this sound like it would work? Can anybody see any way to do it > with less than three files? AFS offers both read-locks and > exclusive-write-locks on all platforms via fcntl(). >
In the latest versions of SQLite (3.3.0 and later) you can provide SQLite with customized locking code at run-time. So you can easily add AFS support that uses whole-file locking instead of the goofy byte-range stuff I have to do for Win95. I expect that code to handle additional locking styles (such as separate lock-file locks for broken NFS systems or for file systems that do not support any kind of locking natively) will be added to the standard SQLite distribution in the near future. If you can wait, you might want to add AFS locking to that module as another option. -- D. Richard Hipp <[EMAIL PROTECTED]>
