[ZODB-Dev] CMS on top of ZODB
Dieter Maurer
dieter@handshake.de
Sun, 9 Feb 2003 09:36:58 +0100
The company I am working for used S=F6rman-CMS (formerly POET-CMS),
an SGML/XML Content Management System on top of the POET object database.
Unfortunately, S=F6rman Germany went bankrupt and
we do not trust the company that took over the CMS to fulfill our
support requirements (as it took over only the software but no people
involved with its development). Therefore, I am exploring the possibility
to implement our core requirements on top of ZODB.
Core requirements are:
* management of many (in the order of hundreds of thousands) SGML/XML
documents, some of them in the order of several MB in size
* documents are made up of components with versions (called
"history" in Zope/ZODB) which can be shared between
documents
* highly concurrent use (about 200 concurrent active users with
write access; steadily increasing)
* stress read access during production (of publications produced
out of the CMS)
* X-Metal integration (on top of an intranet protocol).
* High availability/replication
I think I will be able to implement about 90 percent of these core
requirements on top of ZODB in a matter of weeks.
However, there are some tricky issues, I would like to discuss:
* ZODB's optimistic concurrency control
It requires that the probability of conflicts is low (fullfilled
in our setup) and the effect of conflicts is not desastrous
(not fullfilled in our setup; checkins can take many minutes
and it were bad when they had to be retried due to conflicts).
If necessary (after having exhausted application specific conflict
resolution), I would implement (object) locks in the ZODB:
Read locks would do nothing except prevent to acquire a write lock
(by a different connection) and to write the object.
Write locks would prevent to acquire other locks on the object
and behave like a simulated write (with identical content)
with respect to cache control.
* Versioning/History
ZODB's version/history support is almost identical to that implement=
ed
by S=F6rman-CMS. Its only drawback: it gives us only very limited
control over the versions.
I think, we could enhance the packing process to recognize
special objects (based on classname) to hold references
to older versions. We could then use a standard marking
garbage collection for packing: current versions and
versions referenced by (current) special objects are
in use; any version referenced by a version in use is in
use.
The "version referenced by a version" is a bit tricky, as
a version references another version only indirectly:
it directly references an object and it is associated with a time;
it references the object's version that was current at this time.
Of course, packing would become considerably more expensive...
What do you think about the prospects of these extensions?
I can make extensions to ZODB (with respect to programming skills
and employment contract obligations) and donate them back to the core,
when you are interested...
Dieter