Article 162452 of comp.os.vms:
Thanks for those who responded to me about this problem.  I'd like to send a 
general summary to the newsgroup.

My problem was that I wanted to cache a database across several nodes where 
there would be many processes on each node sharing the cache.  I originally 
hoped to be able to memory-map the file into a global section on each node.  
The problem is that there isn't a way automatically update a file-backed 
section in memory if the file itself changed (possibly because of an update 
done by a different node).

So what I've decided to do is use a pagefile-backed global section on every 
node and have (at least) one process on every node acts as a "listener" which 
would update the global section by re-reading the file when the file changed.

I think I'm going to end up with two different locks to handle this.  There 
will be one lock per node which handles access to each global section and then 
one global lock which handles updates to the file.  If a process needs to 
update an entry in the database, it must get both locks.  The "listener" 
processes will have a blocking AST on the master lock, so when the updating 
process gets the file-update lock, it will signal the "listeners" to update 
the section on the local node.  The other processes will have a blocking AST 
on the local cache so that when an update occurs, they will drop their locks.

This could all be handled by one lock, but this database is being added to an 
already existing system, and it will be more efficient to use this two-lock 
scheme.  Mostly because with a two-lock scheme, a process on a node will only 
have to wait for the local listener to update the local cache instead of the 
process having to wait for all remote listeners to update all of the remote 
caches before it could access the local cache again.

I may also split the master-update lock into various sublocks so that when a 
record is updated, only part of the master file must be re-read by the other 
listener processes instead of the entire file.

Note that this is all a simplified version of how I'll implement this.  There 
are details to be worked out to prevent unneeded cache updates and unneeded 
lock-thrashing when an update occurs.  These problems can be handled by using 
sequence numbers in the file and in the lock value-blocks.

I'd like to point out that the only reason this whole mess is useful is 
because database updates will be relatively rare.  If database updates were 
fairly common, this type of scheme  would have too much overhead. It doesn't 
surprise me that DEC didn't solve this problem already since it isn't an easy 
problem to solve correctly and efficiently in general.
 
+===================================================================+
Ryan Moore (T-510R)         Qualcomm, Inc.         work:(619)658-2990
rmoore@qualcomm.com                                home:(619)549-1634
 The ideas and words in this message are my own, not my company's!!
+===================================================================+