[Persistence-sig] A simple Observation API

[Phillip J. Eby]

At 09:34 PM 7/30/02 +0200, Sebastien Bigaret wrote:
>
>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?
>

Yes, if I've understood you correctly.  My point was that it's easier to
implement scenarios such as you described, with the "write-throughs during
commit" algorithm, as it doesn't need to explicitly track all those
dependencies.  Yes, it may cause occasional inefficienct write operations
when there is a complex cascade taking place, and the participants are
registered in a less-than-optimal order, but the idea is for "complex
things to be possible", while keeping simple things simple, and ideally to
guarantee correctness.

That's why, in the absence of other information to the contrary, I favor
the "write-throughs during commit" algorithm for handling dependencies.  It
scales the best for complex scenarios, guarantees correctness for any
non-circular dependency graph, and involves the least code to be written
for even the simplest cases, with the possible exception of how persistent
objects issue change notifications.