Configuring the DbEnv for multi-process single-writer scenario

Question

I have (1) a multi-process server program (Apache/PHP) using the XML container read-only and (2) a couple of scripts (Perl, PHP, whatever), one of which may be performing update work on the data at any given moment. There is, however, no concurrent write access.
Write access, if I've understood correctly, commands the use of transactions in a multi-process scenario. Specifically, I'd use:
* DB_INIT_MPOOL, DB_INIT_LOCK, DB_INIT_LOG and DB_INIT_TXN when creating the environment, so that all subsystems that will eventually be needed are in place;
* DB_INIT_MPOOL, DB_INIT_LOCK, DB_INIT_LOG and DB_INIT_TXN for writing;
* DB_INIT_MPOOL for reading.
Please correct me if these assumptions are somehow flawed or simply wrong.
Do I need more flags?
Now, in the Berkeley DB Reference Guide, I read about Berkeley DB Concurrent Data Store Applications and the DB_INIT_CDB flag. I wonder if (a) this information also pertains to BDB XML and (b) this fits my scenario - only one write process at any given time.
If I can use DB_INIT_CDB, what will I gain with respect to the scenario laid out above, or any other possible scenario?
Michael Ludwig

Answer 1

Hi John,
thanks for pointing out that the flags used to open the environment have to be consistent among all applications.
As for CDB:
CDB puts a single big lock around the database, and
won't let any readers get access to anything while a
writer is operating. Generally it is advisable to use
transactions in preference to CDB, which will allow
concurrent reads and writes. You should also consider
using MVCC, to increase concurrency more.Thanks for this info on MVCC. I remember reading an interview with the Interbase (then Groton Database) developer Jim Starkey, who seems to have invented MVCC, in which he told how, one morning in the shower, it appeared to him that multi-version concurrency control was the solution to almost all problems. Well, database problems, maybe.
I read about MVCC in your Transaction Guide.
http://www.oracle.com/technology/documentation/berkeley-db/xml/gsg_xml_txn/cxx/isolation.html#snapshot_isolation
"What [MVCC] means is that every time
a writer would take a read lock on a page,
instead a copy of the page is made and
the writer operates on that page copy.
This frees other writers from blocking
due to a read lock held on the page."
I think an application featuring high concurrency of read and write operation will benefit from MVCC, provided there is enough memory to accomomate all the page copies. And I will eventually need this.
At the moment, however, the update is done using the typical nightly crontabbed batch job. Not much traffic expected during the update, and no updates while the site is busy. I doubt I have much to gain from MVCC in this primitive scenario. What do you think? Would I still benefit from MVCC, or would I only incur the copy overhead without benefitting from it for lack of read-write concurrency?
Michael