Page Comparison

If you look at the Miss Quackfaster example for the unit of
work, be aware that, at the same time, behind the scenes,
client transactions were created for each new form (by re-call).
These client transactions are not created equal. The first client
transaction - the one for the Boss instance - becomes the
root transaction from which another client transaction is spawned
off as its "child-" or "sub-" transaction (sub-transaction). This root
transaction is ultimately responsible for actually committing all the data to the
database that has been accumulated during the unit of work
(unless something goes wrong or Miss Quackfaster clicks Cancel
instead of Save).

So walking the link/reference/relation from the boss to the car
spawns off a sub-transaction, with the aforementioned root transaction
as its parent. In contrast to the root transaction, the sub-transaction
is not responsible for writing data to the database. If everything
works out, data is passed to the parent transaction, in the hope
that Miss Quackfaster will click Save in the Boss form, and the
root transaction will write the modification to the database.
On Miss Quackfaster's way from the car object to the fax object
another sub-transaction is spawned off, this time with the
aforementioned sub-transaction as its parent – making the root
transaction the grand-parent, so to speak. This new transaction
doesn't store anything in the database, either. Instead it passes its
modification (the fax-number, remember?) to the previous generation –
the sub-transaction for the car, that is. Here is a (simplified, not
quite accurate) illustration of the process.

...

The red rectangles are client transactions, each of which is
ultimately descendent from the root transaction, or root transaction
itself (on the bottom of the picture). Just as sub-transactions are
spawned upwards, data is copied downwards as soon as a child transaction
commits its data – typically when the user clicks Save. The root
transaction, ultimate ancestor of all sub-transactions, finally commits
to the database – typically when the user clicks Save.

The fact that the domain object boxes are drawn inside the red
client transaction-rectangles is not just artistic license. Remember
that object data is loaded into and stored in transactions. A domain
object is an empty shell with properties that don't contain values.
Instead, properties know which (sub-) transaction actually holds these
values and can retrieve them from there.

...

• transactions can spawn off sub-transactions, forming parent-
  transactions and child-transactions
• data is passed from child (i.e. sub-) transactions to
  parent transactions if and when the child transaction is told to Commit()
  its data
• the client transaction with no parent - the root transaction - actually
  writes data to the database if and when the root transaction is
  told to Commit() its data

In a word: sub-transactions are spawned up the generations, data
bubbles down the generations. When a user modifies and saves data
in many objects stored in one or more sub-transactions, these modifications
aggregate in the parent transaction. If the user cancels that parent
transaction, these modifications from sub-transactions will be discarded.
Not before the aggregated modifications on the bottom root
transaction are committed, will all modifications be persisted.