Features of the Update 
The following figure shows you how the SAP system and the database interact when an SAP transaction is being executed, and illustrates the difference between a database LUW (logical unit of work) and an SAP LUW.
This figure shows an SAP transaction that represents an SAP LUW. The transaction consists of a dialog part extending over three screens. Each screen can be processed by a different (dialog) work process, because while the system is waiting for the user to make an entry, the work process can be assigned a different task by the dispatcher.
The dialog part is completed with the command COMMIT WORK, and then the update part of the transaction starts: The update server passes the update request to an update work process. Each dialog step (time interval between two screens) here corresponds to a database transaction (database LUW, completed with a COMMIT to the database, that is either executed in full or not at all on the database). The update part of the SAP transaction is executed in a database LUW. It is in this database LUW that the data is actually transferred into the application table.
Difference Between Database LUWs and SAP LUWs
To the database, an LUW is an indivisible sequence of data operations that must be completed in its entirety or not performed at all. Database LUWs are the building blocks out of which database procedures for consistent data-handling are built.
By way of contrast, an LUW for the SAP System is a business process, which cannot be divided up. The process is either executed in full or not at all. An SAP LUW must include several database LUWs (see figure above), each of which can be terminated with a database COMMIT, which is generated automatically. Under normal circumstances, the SAP LUW contains a dialog part (which maps a business process), and the command for writing the data to the database (update part).
For each database LUW, the data is written to the database, but not to the application tables, rather to special update tables. If the dialog part has ended, all the data is copied to a database LUW in the application tables. The update request is executed.
Advantages of the SAP Update System
The updating system offers a variety of advantages over direct database changes inline in a transaction. These include:
Problems that arise as a result of different types of “logical units of work” (LUW) for database systems and SAP transactions are avoided. By bundling updates, the update system supports critical rollback and restore functions for transactions.
Improved performance for dialog transactions: Long database changes are made asynchronously at the end of the LUW, if the user is already in the next LUW.
To improve performance further, application programmers can configure various types of updates:
Time-critical V1 updates
Non-time-critical V2 updates, dependent on V1 updates
Non-time-critical V2 updates that are collected and processed at a later time (collective runs)
RFC and Update
RFC and HTTP calls behave differently to normal in the update process. There is no implicit database commit and no rollout
If, however, a database commit or a database rollback does happen to take place during the execution of the update, the update is canceled.