Object-Oriented Transactions in Classic Applications

In a classic application, statements that change the database normally are programmed in update modules. These changes are registered during program execution and the change is triggered with the COMMIT WORK statement.

If you access the services of the Object Services in a classic application, that is, if you are working with a persistent object or you started an object-oriented transaction, an implicit top level transaction is automatically created and started in compatibility mode the first time the services are accessed. All explicit accesses to the Persistence and Transaction Service are embedded in this implicit top level transaction.

If COMMIT WORK is triggered in a classic application, the top level transaction is also ended and the Transaction Service starts updating all the persistent objects that were changed up to this time. The persistent objects are updated as in classic applications. Similarly, all changes to persistent objects within the top level transaction are canceled by a classic ROLLBACK WORK.

In particular, the changes that were confirmed in object-oriented subtransactions with method END are made, whereas changes that were canceled with UNDO are not affected. It can therefore be advisable to work with object-oriented (sub) transactions also in classic applications to have access to an easy-to-use COMMIT/ROLLBACK mechanism.

Classic Update in Object-Oriented Transactions

Object-oriented transaction mode is set for object-oriented transactions. The top level transaction is the first transaction to be started explicitly.

Within a program in object-oriented mode, classic components that use and register classic update modules might be called. This is possible as long as none of the classic components trigger the COMMIT WORK statement, since this would result in a runtime error in an object-oriented transaction.

An update is triggered by the implicit COMMIT WORK at the end of the object-oriented top level transaction. If another object-oriented transaction is started in a called classic component, it is automatically the subtransaction of the top level transaction and is also updated when it ends, before the persistent objects.