<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
Hi,<br>
<br>
some minutes ago I realised, that support for BDB is gone in ZODB3
3.3.2. This is really hard for me, because I decided to use BDB as my
main storage. :-((<br>
<br>
I don't have a problem without BDB if there is a comparable storage
available - but I can not see such storage. I need to store some 100's
GB in a distributed way (ZEO). BDB is doing this in a nearly perfect
way - fast, reliable and a small administration overhead.<br>
<br>
The alternatives:<br>
<br>
1. FileStorage: Needs to much memory for big databases.<br>
2. APE: No ZEO support, Alpha quality, no versions<br>
3. Directory-Storage: Only 1 Maintainer and a "problematic technical
design" (Filesystem as databasefile??), no versions<br>
<br>
<br>
I can not understand the reasons for stopping BDB-Support at
<a class="moz-txt-link-freetext"
href="http://zope.org/Wikis/ZODB/BerkeleyStorageDocs/BDBStorage.html">http://zope.org/Wikis/ZODB/BerkeleyStorageDocs/BDBStorage.html</a><br>
<br>
<br>
<ul class="simple">
<li>The usual range of bug reports against an immature
implementation.
For example, reports of autopack not working, and of manual packing
never completing -- even reports of packing <em>increasing</em>
storage
size.</li>
</ul>
immature?? autopacking works perfectly!!<br>
<ul class="simple">
<li>A way to prevent unbounded growth of Berkeley log files, without
shutting down the app. This is apparently complicated due to that
the ZODB BDB storage implementations disable Berkeley DB's native
locking
mechanisms (a large transaction could require more locks than bsddb
can provide).</li>
</ul>
a cronjob is running moving the logfiles, I tested with 300GB
transactions without any problems !!<br>
<ul class="simple">
<li>The maze of incompatible Berkeley DB distributions on different
platforms. A striking example of this problem was that the ZODB
Berkeley tests died with segfaults if the platform had a more recent
version of Berkeley DB than the ZODB code was developed against.
There was a long history of version-specific ZODB BDB test failures
before that.</li>
</ul>
different versions of different software have to adjust - that's part
of softwaredevelopement.<br>
<ul class="simple">
<li>Tuning Berkeley DB for performance appeared complicated,
difficult,
and necessary.</li>
</ul>
indeed - I had to set some parameters in DB_CONFIG (set_lg_dir
/dumpdir/archive_logs/bdb/dms, set_tmp_dir /tmp/bdb, set_lg_max
419430400, set_lg_bsize 104857600, set_flags DB_TXN_NOSYNC) - is this
a problem ???<br>
<br>
<br>
I really don't understand the descision - specially because there are
no alternatives in sight.<br>
<br>
Any suggestions?<br>
<br>
Harald<br>
<br>
<br>
<br>
<br>
<br>
<br>
<pre class="moz-signature" cols="72"></pre>
</body>
</html>