[Zope-CMF] Re: Recipe for ReadConflictError hell
dieter at handshake.de
Tue Dec 7 15:22:51 EST 2004
Tres Seaver wrote at 2004-12-7 11:23 -0500:
>>>Here's a way to kill your CMF performance and grow your Data.fs hugely ;-)
>>>1. Add a new skin folder to one of your products
>>>2. Add this skin folder as a FSDV in your portal_skins tool, and insert
>>>it into one of the skin definitions your using on the properties tab.
>>>3. Delete the skin folder
>>>4. Restart Zope
>>>5. View your CMF site and watch the conflict errors roll in :-(
>I'd be inclined to wonder if this isn't related to the same bit of
>Windows-only code which Dieter always nags Chris about.
>Chris, can you reproduce on Linux?
It is not reproducible on Linux (with my Zope 2.7.2, CMF 1.4 version).
But while the Windows-only code (which I nag Chris about)
is eating lots of processor cycles, I have never heard that
it would write to the ZODB. In fact, I doubt it is to blame
I suggest that Chris verifies with "fsdump" which objects
are written in these transactions ("fsdump" will tell him
the "oid"s and the classes).
If they are really "FSDirectoryView" instances, then
a fix I have made in our CMF version might be relevant:
I found out that the "_v_eek" attribute
were written through the surrogate into the underlying
"FSDirectoryView" object: The "__setattr__" of
"DirectoryViewSurrogate" writes to both the surrogate
and the "FSDirectoryView" itself. This caused very
strange error handling behaviour for us (fixed
by defining a "__delattr__" along the same line as "__setattr__").
This behaviour of surrogates means that one must use "_v_" variables
to avoid ZODB writes even though the surrogates themselves are not persistent.
More information about the Zope-CMF