Is "set update task local" more consistency friendly than "commit work and wait"?

[phoenixming0912]

Hi all,

For a given API, I don't know if an update module is inside and it's update priority.

Is it better to use set update task local than "commit work and wait" from a data consistency view?

Could you please provide information like there advantage or the difference between them?

Besides, does it also have influence on ROLLBACK WORK?

Regards,

Eric

[Sandra_Rossi]

There are 3 possible scenarios:

1) Classic. The update task starts asynchronously to run all V1 update function modules:

CALL FUNCTION '...' IN UPDATE TASK ...
COMMIT WORK. "<== starts update task asynchronously to run all update function modules
" next statements run before the asynchronous update task has ended

2) Same as 1 but wait for Asynchronous V1 update function modules to be terminated:

CALL FUNCTION '...' IN UPDATE TASK ...
COMMIT WORK AND WAIT. "<== starts update task asynchronously to run all update function modules + wait
" next statements run after the asynchronous update task has ended

3) Same as 2 (on the effects you observe) but the update task runs locally in the same work-process, so it's synchronous - AND WAIT makes no sense/is not needed:

SET UPDATE TASK LOCAL.
CALL FUNCTION '...' IN UPDATE TASK ...
COMMIT WORK. "<== runs all update function modules synchronously
" next statements run after all the update function modules have executed

More information: COMMIT WORK, SET UPDATE TASK LOCAL.

[phoenixming0912]

It seems like "commit work and wait" only wait until V1 priority update tasks finished.

So is use case 3 more restrict than use case 2? Is there any other difference between these two measures?

[Sandra_Rossi]

That's correct, I meant the V1 update function modules (fixing my answer). V2 function modules are always executed asynchronously, and V3 ones are executed by a specific batch job (V2/V3 = "low priority" function modules).

Differences are about performance/architecture, there's no visible difference for a developer. I sometimes used SET UPDATE TASK LOCAL to force a synchronous execution when I had no possibility to add AND WAIT to an existing COMMIT WORK (+ forcing a synchronous execution can also be done via Batch Input through CALL TRANSACTION USING). The differences between 2 and 3 are explained in ABAP documentation of SET UPDATE TASK LOCAL, so it's just about performance/architecture:

• « This statement switches the local update on. In the local update, high priority update function modules that are registered in the current SAP LUW using CALL FUNCTION ... IN UPDATE TASK are stored in the ABAP memory instead of the VB... DDIC database tables. They are executed immediately in the current process and not in the update work process within the current database LUW, when the statement COMMIT WORK is executed. This statement has no effect on low-priority update function modules. »
• « The profile parameter abap/force_local_update_task can be used to set the local update centrally for an AS ABAP. This should be done with great care, however, and while respecting all updates that can take place in the system. If not, the behavior of programs not intended for local updates may change. The performance of database locks may also be affected negatively. »