[Chandler-dev] new --mvcc performance feature

Andi Vajda vajda at osafoundation.org
Wed Jan 3 14:07:33 PST 2007

In version 4.5.20, Sleepycat (now Oracle), added support for MultiVersion 
Concurrency Control (MVCC) to Berkeley DB.

Using MVCC causes commit() to make a copy of the pages it modifies thereby 
allowing database readers such as cursors to operate without acquiring 
read locks. This has three consequences:

   - no more deadlocks:

     even though chandler (Berkeley DB really) detects deadlocks and terminates
     the transaction of the writer causing the deadlock, not having the
     deadlock in the first place makes commit ultimately faster since it
     doesn't have to be retried until no deadlock happens. The best way to
     experiment with that is using the 'Test -> Restore Settings' menu option
     and use a .ini file that lists several collections. Chandler.log should
     not have any 'commit aborted by deadlock' messages and the process should
     complete much faster (assuming the server used delivers on its side).

   - better read throughput:

     item loading, cursor-based iterations such as history, kind queries,
     etc... are faster since they don't have to acquire (and wait) for
     read locks.

   - more memory (cache) usage:

     because commit() has to copy some the pages it modifies, more cache is
     used by an chandler process using --mvcc.

MVCC should be well suited for Chandler's use of Berkeley DB. Chandler's 
repository is versioned and old versions of data are not modified. Instead, 
new versions of data are written. This limits the contention for existing 
pages between readers and writers as well. Therefore, doing away with having 
to acquire read locks should be a performance boost.

See [1] for more information about MVCC and so-called "Snapshot Isolation".

Because this is a new feature in Berkeley DB, I felt it was safer to make it 
experimental and turned on via a new --mvcc command line argument (off by 

It would be good to turn this on on the performance tinderboxes as it's
having a noticeable effect on performance. Also, if it proves stable (as it 
apparently is), I'd like to make it the default in a few weeks...


[1] http://www.oracle.com/technology/documentation/berkeley-db/db/api_c/frame.html

More information about the chandler-dev mailing list