[Persistence-sig] A simple Observation API

[Phillip J. Eby]

At 04:23 PM 7/31/02 -0400, Jeremy Hylton wrote:
>>>>>> "PJE" == Phillip J Eby <pje@telecommunity.com> writes:
>
>  PJE> That's what TransactionAgents does, but that's not what I'm
>  PJE> looking for per se.  I'm looking at simple data managers.  For
>  PJE> example, if I make a data manager that persists a set of
>  PJE> objects to an XML DOM, I might want to use it with a DOM
>  PJE> persistence manager that stores XML documents in an SQL
>  PJE> database.  All three "data managers" (persist->XML,
>  PJE> XML->Database, SQL database) are transaction participants, with
>  PJE> implied or actual ordering.
>
>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? :-)
>

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

But that's an implementation detail.  This is primarily an architectural
issue.  Data manager 1 is generic code written to work on an XML DOM.  It
shouldn't have to *know* that the DOM *is* persistent, let alone *how* it's
persisted.  You're calling for the placement of global architecture
knowledge into individual components, that should only be known at a higher
abstraction level.