I forgot to say in my previous message about --mvcc that to use this new
feature, a new version of chandlerdb is necessary, version 0.6-69.
Use 'make chandlerdb' to upgrade after your next 'svn update'.
Andi..
---------- Forwarded message ----------
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
default).
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...
Andi..
[1]
http://www.oracle.com/technology/documentation/berkeley-db/db/api_c/frame.html
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
