There is a relative of the long business transaction problem that occurs rarely in practice, but when it is needed, it becomes nearly impossible to handle with traditional programming techniques. That problem is the nested transaction: a transaction within another transaction, usually within a long business transaction.

The need for a nested transaction comes up when, in the middle of another transaction, a subset of processing must be accomplished, at the end of which the operator can again either “accept” or “cancel” the sub-transaction. In AOA, this is handled very simply by creating a “subobject version” of a subset of the data in an object (which is called a subobject). There is a command, CreateSubobjectVersion, which requests that the object engine create a copy of the complete subobject being identified. Any number of user iterations can then follow to update data within the subobject. At the end of that sub-processing, the work flow takes either a AcceptSubobject action or a CancelSubobject action, usually based on the user striking a button (as in the example to the left). In the former case, all the data changes become permanent within the object in memory. (Note that this is not yet permanent to the database.) In the latter case, all data changes are ignored and the data in the subobject is restored to its state at the time of the CreateSubobjectVersion command.

Example: In OpenCUAS, a student’s transfer records are maintained as a single, long business transaction. Within that transaction, a group of transfer records for a particular college is specified as a sub-transaction, or “nested transaction.” (In the example to the right, the Object Browser shows the modified flags for the TransferGroup entity to be updated and versioned.) 

Note in the first example above that OK and Cancel buttons are used to trigger either the accept or cancel action. OpenCUAS uses the interface convention that OK/Cancel actions always represent sub-transactions. Save/Cancel actions always represent the conclusion of a long business transaction, where any data changes are either written to the database or dropped.