SAP Data Update

The application layer runs the dialog process, each dialog process binds to a database process, and the dialog process communicates with the GUI. Each GUI's request is assigned a dialog process by the dispatcher service each time the GUI sends a request to the application server. When a program runs, the GUI and dialog need to communicate multiple times, and each communication uses a dialog process that is not necessarily the same. When the dialog process transfers control to the foreground GUI, an implicit database commit (commit work) is triggered because the dialog process binds to the database process, and an implicit database rollback is triggered if a type error occurs in the dialog process (Rollback)
SAP LUW
SAP LUW is an enhancement of the DB LUW, which is limited by the architecture, and the SAP program triggers an implicit database commit when each screen switch (control is transferred from the background dialog process to the foreground GUI session), and a program runs to produce multiple db LUW. This does not make all or all of the rollback, in some business scenarios, the submission mechanism of this transaction is not enough to ensure the consistency of the data, there is an SAP LUW mechanism. SAP LUW is a deferred execution technique that records the blocks that would otherwise have to be executed. The location of the record in memory or DB table, such as perform on Commit, is recorded in memory, and the update Funciton module can be logged to memory or recorded in the Vbmod and Vbmod tables. The system queries the record when it executes the commit work. To actually execute the code that needs to be run, COMMIT work is typically performed on the last screen, which enables the consistency of data updates across the screen by binding to a DB LUW
How SAP Luw is bound
Call FUNCTION ... In UPDATE TASK,
This method requires the Funciton type to be the update module type, while the in update task parameter is used at the time of invocation.
When the program calls the update module for updates, it is divided into local and non-local
Non-native mode:
The registered update function is recorded in the Vbmod and Vbmod tables, and the COMMIT work is executed during the update process, at which time the calling program does not wait for the called function to return, using the asynchronous method. If you use COMMIT work and WAIT, At this point the calling program waits for the returned function to be called, using synchronous mode.
Local mode
The SET UPDATE TASK LOCAL needs to be executed before calling the function. So all after that statement use the call FUNCTION ... The update function registered in the update task is not recorded in the database, but is recorded in memory, and after the commit work, the pending function is taken from memory, the update of the data is performed in the same dialog process, and the local mode update is synchronized, even if the commit After work, the and wait parameters are specified and are still executed synchronously.
The effect of Set update task local after using the commit work is erased, and if the update function registered after the commit works still needs to be local, the Set Update task local statement needs to be executed again.
Pros and cons comparison
Local mode does not write the update function to be executed to the data table, reduce the I/O operation, high efficiency, but because the use of synchronous mode, the program needs to wait for the update results, user interaction will feel the program is slow to run
The non-local method records the results of the update to a data table, which can be viewed through SM13, while the user can feel faster when interacting with an asynchronous update
Call FUNCTION ... In BACKGROUND TASK DESTINATION,
is a way to bind a transaction to an RFC function

PERFORM ... On COMMIT
Registers the block to be executed in memory, you can use the level parameter to specify the priority, the priority is sorted in ascending order, and the smaller will take precedence.
subroutine registered with the on commit parameter, if subroutine of the same name has been registered multiple times, only once in the commit work, the in UPDATE task execution Funciton does not have this restriction
Order of execution of binding methods
PERFORM on COMMIT will take precedence, if interrupted, call FUNCTION ... In BACKGROUND task and call FUNCTION ... In UPDATE TASK, DESTINATION will not execute, which guarantees all data commits and all rollback
It is recommended that you do not mix call FUNCTION ... In BACKGROUND task and call FUNCTION ... In update TASK, because one is a local data update, one is remote data, from a technical guess, cross-database commit and rollback is difficult to implement, so the use of both methods can lead to data inconsistency, unless the local and remote data do not need to maintain consistent data
V1 & V2 Update

Legend Description
Immediate start means the V1 mode, after the update error, can be re-executed in the SM13
Immediate start-no Restrat Possible V1 mode, after an error can not be re-executed in the SM13, some updates out of the specific program after the execution may result in inconsistent data, you can consider using this method
Start delayed V2 mode V1 mode update is completed and triggered,
Collective run V2 mode requires manual or job execution using collective (RSM13005) program,
Update functions are divided into V1 and V2
V1 priority higher than V2,V2 is designed to be dependent on V1 and is suitable for performing operations that need to be done after V1 is completed.
V1 updates are processed using the V1 process, and the V1 process name typically binds a separate database process to the UPD,V1 process. The update function that is scheduled in the V1 process if the update fails, rollback, and no V2 operation. Success commits changes to the database while deleting all SAP locks
The V2 update uses the V2 process, if the V2 process is not configured, the V1 process is shared, the V2 process name is UP2,V2 update in the standalone DB LUW, the V2 update is not affected by the V1 update submission, and the SAP lock is removed after the V1 update ends. So the V2 update is performed without a logical lock and can be re-executed in SM13 after an error V2 update
SAP Locks
The SAP lock is a logical lock, which is handled by the lock function and the lock function.
Lock type
S share Lock read lock, can accumulate
E exclusive Lock Write lock process can accumulate
X exclusive Lock Write lock can not accumulate
Use the S lock with caution, the accumulation of s lock will cause the lock cannot be completely released, resulting in other programs cannot write, E lock can guarantee only one lock
Lock Object
Lock and unlock functions can be generated by locking objects
Where the scope parameter 1 represents the program, valid 2 indicates that the update module is valid 3 all
_wait indicates if the object has been locked, whether to wait and then try to lock, the maximum wait time has the system parameter Enque/delay_max control
The _collect parameter indicates whether a unified commit is collected, COLLECT is a caching and batching method, that is, if COLLECT is specified, the lock information is placed in lock Container, and lock Container is actually a Funciton Group-controlled memory area, if a lot of locks are added to the program, the lock information will be put into memory first, so as to reduce access to the SAP lock management system, the lock in Shut up lock container takes effect, need to perform flush_enqueue this funciton, The lock information is updated to the lock management system, at which time the lock operation takes effect and the lock information in lock container can be cleared using the function reset_enqueue
Release lock
Call the Dequeue function
If a program update is used to V1 update, all locks are deleted in the commit work
Program Abort
Rollback
Why you need to use SAP Lock
SAP Lock is a kind of logical lock, relative to DB lock, is a lightweight lock, DB lock once found unable to lock will delay the wait, using SAP lock to some extent can reduce the use of DB lock, avoid deadlocks, while reasonable use of SAP Lock ensures consistency of data
Other
Select for update is a lock added at the DB level
Reference
SM66 viewing the active process, if there are V1 and V2 updates, you can see the upd and UP2 processes
SM13 viewing errors or V1 and V2 updates that have not been performed