[Persistence-sig] A simple Observation API

[Jim Fulton]

Phillip J. Eby wrote:
> At 08:40 AM 7/30/02 -0400, Jeremy Hylton wrote:
> 
...


> This has to do with the "write-through mode" phase between
> "prepareToCommit()" and "voteOnCommit()" messages (whatever you call them).
>  During this phase, to support cascaded storage (one data manager writes to
> another), all data managers must "write through" any changes that occur
> *immediately*.  They can't wait for "prepareToCommit()", because they've
> already received it.  Basically, when the object says, "I've changed"
> (i.e. via "register" or "notify" or whatever you call it), the data manager
> must write it out right then.
> 
> But, if the _p_changed flag is set *before* the change, the data manager
> has no way to know what the change was and write it.  It can't wait for
> "voteOnCommit()", because then the DM it writes to might have already
> voted, for example.  It *must* know about the change as soon as the change
> has occurred.  Thus, the change message must *follow* a change.  It's okay
> if there are multiple change messages, as long as there's at least one
> *after* a set of changes.

I realize that this issue seems to be resolved by eliminating write throughs,
but I want to make sure I understand something here. I would have assumed that
all changes to persistent objects would occur before commit, and thus before
any prepares are done. You seem to be assuming that persistent objects could
change after the application has issued a commit. Is that right? Is the reason
that the prepare logic of some data managers do their work by manipulating
persistent objects in other data managers?

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (888) 344-4332            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org