The Berkeley based storages have been rewritten to provide a number of benefits over their ZODB 3.1 cousins, including:
- No use of BerkeleyDB locks. Because ZODB uses its own application level
locks
in the storage base class, we don't need to use the BerkeleyDB locks.
This is
win for ZODB because BerkeleyDB locks are static in size, requiring at worst
a lock per object modified in the transaction, plus some fixed overhead.
Because ZODB is theoretically unlimited in the number of objects modified in
a single transaction, there's no way to guarantee we won't exhaust
BerkeleyDB
locks unless we don't use them
. - No temporary commit log. ZODB 3.1's version of the Berkeley storages used a temporary log file which was replayed into BerkeleyDB at commit time. We came up with an implementation trick to avoid the need for this file, so performance and disk i/o usage should greatly improve.
- Rewritten pack(). Pack (for the Full++ storage) doesn't use an in memory memo dictionary, but instead it uses another BerkeleyDB? table. So pack should not be memory pathological.
- Autopack. An experimental facility called "autopack" will be added which will let you set up an automatic packing schedule, which will run in a thread, and will periodically pack the database. So even with a fully versioning database like Full storage, you will never have to explicitly pack.