Mike, if you are going to implement a lock server, why not finish the
job and include Sqlite in the server, then you will not have a problem.
JS
Mike Ashmore wrote:
Hello all,
I'm working on a system in which I'm using SQLite to open a number of
database files and to perform operations on aggregate views of those
files.
The problem I've got is, some of the files I want SQLite to open and
SELECT from, I can only acquire read access to. And the operating
system I'm using doesn't allow me to place any sort of advisory lock on
a file that I've only got read access to (it considers placing an
advisory lock to be a write operation) (@#%!# high security operating
systems).
Since modifying the OS isn't an option, the next step would appear to
be to write some sort of external lock-management server, and have
SQLite redirect all of its fcntl(F_SETLK / F_GETLK) operations to that
server. I was wondering if anybody has done anything like this, and if
perhaps someone could offer some tips on how I might go about it.
Clearly I'm going to have to pass the server the "op" and "struct
fcntl" arguments from what originally was the fcntl call. But since the
lock server will be a separate process, the file descriptor from my
sqlite process doesn't seem terribly helpful in identifying what file
I'm trying to lock. Looking through os_unix.c, I see numerous
semi-inscrutable references to keeping track of inodes, etc; perhaps
the inodes are the unique file references (as opposed to other
process's file descriptors) my lock server should be keeping track of
as well? Won't a given database file span quite a few inodes?
Since locking will require me to invoke (slow) IPC mechanisms, I don't
want to send any more lock messages off to my lock server than
absolutely necessary; any suggestions on how I should approach that?
Thanks in advance for any help you folks can offer on this problem.
-Mike Ashmore
