[Zope-CMF] Replication And Workflows - "Nightmare of CMF Stre et"

[Dieter Maurer]

Norfleet, Sheppard S. wrote at 2003-9-25 08:34 -0700:
 > ...
 > >  *  I think Shane has a DCWorkflow variant that stores workflow
 > >     state outside the object.
 > >
 > >     Should you by chance use this variant?
 > 
 > Yes I do use DCWorkflow, but I previously reviewed the code and my
 > impression was that it was for the workflow content items, not the workflow
 > tool, and its the workflow tool that seems to manage the workflow_history
 > attribute.  I see where DCWorkflow makes calls to the WorkflowTool whenever
 > it needs state/history information.  So if my impressions are right how can
 > it be managing the workflow_history outside of the object?  I will look over
 > the code again...

You can quit this route.
Apparently, you do not have this special variant.

 > >  *  You mention separate threads.
 > >
 > >     Are you aware that a separate thread can easily read stale
 > >     data unless it plays well with the ZODB transaction
 > >     machinery?
 > >
 > >     Invalidation messages (caused by modification of objects)
 > >     are only handled at transaction boundaries.
 > >     Unless your separate thread commit/aborts the transaction
 > >     it is highly likely that it sees stale object state.
 > 
 > Yes, I defined a _p_independant function and bracketed transactions with
 > synchronization locks and have gotten rid of the ZODB conflict errors that
 > plagued me for a long while.  I also refresh the DB connection on each pass
 > by the replication thread in the hopes that it might combat stale data, but
 > thats simply the tactics of a novice's mind.

And you have "get_transaction().begin()" at the start of the pass
and "get_transaction().commit()" or "...abort()" at its end?


Dieter