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

[Norfleet, Sheppard S.]

Dietur,

Thanks for getting back to me so quickly.  I humbly submit I am still have a
lot to learn about Zope and CMF.

>  *  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 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.

Thanks Again,

Sheppard

-----Original Message-----
From: Dieter Maurer [mailto:dieter at handshake.de]
Sent: Wednesday, September 24, 2003 9:56 PM
To: Norfleet, Sheppard S.
Cc: 'zope-cmf at zope.org'
Subject: RE: [Zope-CMF] Replication And Workflows - "Nightmare of CMF
Stre et"


Norfleet, Sheppard S. wrote at 2003-9-24 11:51 -0700:
 > ...
 > I think _setObject is not the problem after all.  I am wondering if the
 > location of my replication product and the use of physical paths is
causing
 > the problem.  

Very unlikely.

 > ...
 > In the replication product I store the object as a physical path, which
will
 > be unrestrictedTraversed to later using Moniker's bind (actually done in
a
 > separate thread), from there the object will be replicated.  
 > 
 > Well heres the deal, when I get the object originally, replicateCreate(),
I
 > cannot see the workflow_history attribute, and later when I traverse to
the
 > object's path and recover the object in a separate thread,
 > checkReplicationQueue(), I still cant see the workflow_history attribute;
 > yet , through the web I can as I changed WorkflowTool to print (to the
 > console) the workflow_history attribute when it retrieves it.  

Two ideas:

  *  I think Shane has a DCWorkflow variant that stores workflow
     state outside the object.

     Should you by chance use this 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.

 > ...
 > So now I am sure its not _setObject, but something in the acquisintion
 > engine is preventing me from accessing the attribute,

You can be sure this is not the case.



Dieter