You might wonder why the scheme of root- and sub-transactions is so complicated in first place. Why not have a single transaction for a session? Why can't we store data in the database immediately whenever a user clicks Save?
The example of Miss Quackfaster and her Boss' car-fax is not only contrived, but also simplistic. We used it to explain the basic mechanism (FIXME). Observe that
All this can make single transactions or immediate saving problematic. A less simplistic, more realistic example is that of Miss Quackfaster trying to order an electric pencil sharpener and a lunch for her boss for immediate delivery by the procurement group. Let's say, that, for technical reasons, procurement is supposed to be conducted in bulk, for as many items at once at possible. For her boss' lunch and pencil sharpener, Miss Quackfaster opens the central procurement form and
All this takes place during a single transaction started in the Boss window. Note how complicated Miss Quackfaster's way through the maze of decisions and forms is. Also note that
Here is an illustration of Miss Quackfaster's procurement adventure:
As you can see in the illustration, the unit of work is structured as a tree. Just as in the illustration before, green arrows show Commit()
s to the parent transactions, with (13) as the ultimate Commit()
to the database. Note that data can move toward the database only if the parent nodes let them. If Miss Quackfaster decides to cancel a node, the modifications for all its children are discarded. This aids the user in complicated units of work like this: If you cancel a form, all forms you had open before are as good as gone. Building child transactions along the way through the maze of windows aids the programmer, because it is easy to keep track of data. This would be hard (if not impossible) to track in a single client transaction, because then the programmer would have to build his tree-like data structure outside his client transaction. SOME mechanism is required to decide which modifications must be discarded if Miss Quackfaster decides to cancel an entire branch of previous Commit()
-s. Making client-transaction simpler wouldn't make things easier, it would put the burden of managing parents and children on the programmer (you). If your desire a less fancy and more flat, you CAN use a single transaction. The parent/child-architecture of client transactions lends itself very well to the problem branching in units of work, because it can mirror the behavior of users who quite naturally fork, branch and detour to their hearts' content through trees of interconnected domain objects.