[Zope-CMF] Re: Recipe for ReadConflictError hell

[Dieter Maurer]

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
for this.


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
  (from "OFS.SimpleItem.SimpleItem.raise_standardErrorMessage")
  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.

-- 
Dieter