No, all of Berkeley DB's built-in concurrency and transaction control is predicated on a DB 'Environment', which, among other things, contains shared memory segments. So all processes/threads that are under transaction control must be on the same computer. My application runs on multiple computers sharing an NFS mount, and under this architecture the BDB Environment structures will not work properly.

What I was looking for was information from anyone in the know about BDB's Memory Pools (the structures that implement the caching layer in BDB). What I wondered is whether these memory pools were smart enough to detect when a file had been modified by some agnet outside of their control and could then be made to invalidate any cached pages for that file. What I've been able to find on the Web so far is inconclusive, but it doesn't look like there's any mention of such smarts being a part of this technology. Therefore unless someone can tell me otherwise I think I'm stuck with closing and reopening database connections every time I want to obtain a lock and do work in order to assure that the caching is not invalidated by work done by other processes since the last time I had a database lock.