[Persistence-sig] A simple Observation API

[Jeremy Hylton]

[Meta-comment: I'm sorry it's taking us so long to reach some kind of
understanding on this issue.  It seems like we keep talking past each
other, but I'm not sure why.]

>>>>> "PJE" == Phillip J Eby <pje@telecommunity.com> writes:

  [I wrote:]
  >> If I understand this example correctly, then there are three
  >> different objects that implement the resource manager interface:
  >>
  >> 1. persist->XML
  >> 2. XML->Database
  >> 3. Database
  >>
  >> It sounds like the application code only interacts with 1, and
  >> that 2 and 2 should be considered implementation details of 1.
  >> Thus, only 1 should register with the transaction, since it's the
  >> only independent entity.
  >>
  >> When the transaction commits, it first calls prepare() on 1.
  >> This delegates the responsibility for the commit to 2, which in
  >> turn delegates to 3.  So for 1 to return True from its prepare, 2
  >> and 3 must also return True.
  >>
  >> Why doesn't this work? :-)
  >>

  PJE> Because 3 would be shared by other objects also being persisted
  PJE> to that SQL database, for just the first thing that comes to
  PJE> mind.

If you call prepare() twice on a resource manager, it should return
the same answer both times, right?  If so, then it shouldn't matter if
the same resource manager is being used as a top-level component and
an internal component.  It will perform its prepare work the first
time it is called and then just return its vote the second time it is
called.

  PJE> But that's an implementation detail.  This is primarily an
  PJE> architectural issue.

I agree that it's an architectural issue.  (It's good that we agree on
some things <wink>.)  The example above sounds like a component-based
system, where there is a compound persist->xml->database component.
The subcomponents of this entity should not be registering themselves
with the transaction manager.  A component should control all
communication of its constituent parts with other components.

  PJE> Data manager 1 is generic code written to work on an XML DOM.
  PJE> It shouldn't have to *know* that the DOM *is* persistent, let
  PJE> alone *how* it's persisted.

The description of the first component implies that is supports
persistence objects and stores them using another component that
stores XML.  That top-level component *must* know how to handle
persistent objects and transactions, as it implements those
interfaces.

  PJE> You're calling for the placement of global architecture
  PJE> knowledge into individual components, that should only be known
  PJE> at a higher abstraction level.

I thought I was arguing the opposite.  Individual components should
not all talk to the global transaction manager.  Instead, when a
component is assembled, the parts should be wired together so that
each knows who to communicate with.

Jeremy