[Persistence-sig] A simple Observation API

[Sebastien Bigaret]

> At 08:40 AM 7/30/02 -0400, Jeremy Hylton wrote:
> >>>>>> "PJE" == Phillip J Eby <pje@telecommunity.com> writes:
> >
> >  PJE> Well, the example implementation I wrote took care of all of
> >  PJE> that, quite elegantly I thought.  But for my purposes, it's
> >  PJE> sufficient as long as _p_changed is set after the last
> >  PJE> modification that occurs.  It's okay if it's also set after
> >  PJE> previous modifications.  It just must be set after the last
> >  PJE> modification, regardless of how many other times it's set.
> >
> >  PJE> This requirement on my part has strictly to do with data
> >  PJE> managers that write to other data managers, in the context of
> >  PJE> the transaction API I proposed.
> >
> >Can you explain how _p_changed is used outside of transaction control?
> >I still don't understand how the timing of _p_changed affects things.
> >
> 
> 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.

I'd like to add a few words here, saying that cascaded storage is not the only
case where "write-through" mode is involved: the so-called 'cascade', i.e. one
DM writing to a lower-level one, can be ``transverse'' as well, i.e. one DM
writing to another one, at the same 'level'. Just an example here: say you
have DM1 and DM2 being responsible for RDBMS DB1 and DB2. If obj1 and obj2 are
to be stored within, resp., DB1 and DB2, then you can have that sort of
``write-through'' mechanism being triggered as well. The reason for this is
that, if obj1 and obj2 are in relation with each other, and since informations
needed for relationships are mostly stored in RDBMS in an asymetrical manner
(put it simply: this info==a foreign key, stored in only one of the two
tables), a change in one of the object needs to be forwarded to the other DM.

  Humm...

  Having writing this, I'm not sure this is related to what you're saying
  here, mainly because the forwarded informations I'm talking about is *not*
  in the object's properties... or is it? Well, changes are *not* in the
  original obj1's properties (although changes might be propagated bottom-up,
  but that's another story), but changes are made in the corresponding 'row1'
  's properties (at DM1 level). So, if DM1 is already in write-through mode,
  it will in turn immediately notify/write to its
  SQL-database-connection-DM. We will potentially have more than one SQL
  statement issued for a single row/whatever, but the necessary informations
  about the whole architecture and dependencies (which the DMs do know) do not
  have to be put into the Transaction framework.

  If this is it, it makes me think that it is like having the DMs calling a
  (reentrant) version of 'prepareCommit()' on their level-1 DMs --but the
  actual forwarding of the message is not explicit, rather made implicit
  through the 'write-through' mode.

Is this what you mean?

-- Sebastien.