ARTICLE
Transaction Service and Updates
ABAP objects and the Object Services are part of a hybrid world in which
object-oriented and classic applications as well as mixed forms
containing both programming styles can exist side by side. The
interaction between classic and object-oriented update techniques is
discussed below.
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 when
programs are executed and the change is triggered with the
COMMIT
WORK statement.
If the services of the Object Services are accessed in a classic
application, that is, if a persistent object is used or an object-o
riented transaction started, 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 executed 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 Updates in Object-Oriented Transactions
Object-oriented transaction mode is set for object-oriented
transactions. The top level transaction is the first transaction to be s
tarted 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 execute 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.
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved