commit work

[Former Member]

hi,

In program ZPRG am calling PERFORM f_xyz(ZSUB). There exists a COMMIT WORK syntax in ZSUB. It takes forever and so the command doesnt return back to ZPRG.......any ideas?

[Former Member]

Hi Ram,

It can not be because of COMMIT WORK. There must be some endless loop or statement which is taking lots of time.

Just check in debugging.

Regards,

Atish

[Former Member]

commit work take more time.

Persistent Objects and COMMIT WORK

To apply the changes made to the runtime objects of persistent classes to the actual persistent objects in the database, execute the COMMIT WORK statement. (Alternatively, use COMMIT WORK AND WAIT or SET UPDATE TASK LOCAL). Unless you are executing an object-oriented transaction from within the Transaction Service, you must include the COMMIT WORK statement explicitly in the program. Otherwise, it is encapsulated in the Transaction Service. (If you explicitly include the COMMIT WORK statement as described here, the t op-level transaction runs in compatibility mode).

The function of the COMMIT WORK statement is extended when you use it in conjunction with Object Services. Before COMMIT WORK closes the SAP LUW and triggers an update, it calls internal methods of the Persistence Service. These methods bundle the changes made to managed objects of the Persistence Service and pass them to a special update function module using CALL FUNCTION ... IN UPDATE TASK. Thus the Persistence Service works with traditional update methods. The update module is usually registered after any update modules that have already been registered. The update is then triggered and the update task executes the update module in the order in which they were registered.

After the system executes the COMMIT WORK statement, it sets the attributes of each persistent object in the ABAP program to initial. (That is, it calls the IF_OS_STATE~INVALIDATE method).

Local Update

If you want to change managed objects directly, rather than using the update module, you must change the update mode of the implicitly used Transaction Service. That is, the following statements must be executed before the COMMIT WORK statement:

DATA TM type ref to IF_OS_TRANSACTION_MANAGER.

DATA T type ref to IF_OS_TRANSACTION.

...

TM = CL_OS_SYSTEM=>GET_TRANSACTION_MANAGER( ).

T = TM->GET_CURRENT_TRANSACTION( ).

T->SET_MODE_UPDATE( OSCON_DMODE_DIRECT ).

COMMIT WORK.

To ensure database consistency, the local update is activated internally using SET UPDATE TASK LOCAL. In such cases, the system raises an exception if there are already update modules registered in the update task. You can only register additional classical update modules after setting the mode. They will then also be updated locally.