Transactions can consist of independent parts. With our invoice example, the
addition of the entire invoice can be considered a transaction, as can the posting
of each part of the invoice. Each of the posting changes involved with an invoice
is treated as one transaction. In this kind of a situation, you have the following
sets of entries in the log file:
BEGIN transaction 1 "Add Invoice"
BEGIN transaction 2 "Post ar jones"
... posting changes ...
END transaction 2
... addition of header ...
BEGIN transaction 3 "Post in widgets"
... posting changes ...
END transaction 3
... addition of detail ...
BEGIN transaction 4 "Post in gadgets"
... posting changes ...
END transaction 4
... addition of detail ...
BEGIN transaction 5 "Post tx city"
... posting changes ...
END transaction 5
... update of trailer
END transaction 1
BEGIN transaction 6 "Add Invoice"
... and so on ...
This kind of nesting is allowed and often desirable. It eliminates the need for lower level routines to know what is happening at the upper levels.
In the case just presented, the posting routine marks the starting and ending point of the changes it makes. At the end of the changes, the posting is consistent and all balances have been updated. Should a posting transaction not complete, some of the balances could be updated but not others. In this case, the transaction is not restored and the balances stay consistent.
At the user_edit level, the addition of an invoice must balance. This means that total debits must equal total credits. If the transaction completes, we know that the book's accounts are balanced. Should the transaction not complete, the book's accounts are out of balance. In this case, the entire transaction is not restored, and the books stay in balance.