LUW at queue level

[Former Member]

Hi

what is LUW at queue level ??

thanks

kumar

[Former Member · Accepted solution]

Hi,

Hope this link helps u in having a understanding about LUW.

http://help.sap.com/saphelp_nw04s/helpdata/en/41/7af4bca79e11d1950f0000e82de14a/frameset.htm

vasanth

[Former Member]

Hi !!!

A logical unit consisting of dialog steps, whose changes are written to the database in a single database LUW is called an SAP LUW. Unlike a database LUW, an SAP LUW can span several dialog steps, and be executed using a series of different work processes. If an SAP LUW contains database changes, you should either write all of them or none at all to the database. To ensure that this happens, you must include a database commit when your transaction has ended successfully, and a database rollback in case the program detects an error. However, since database changes from a database LUW cannot be reversed in a subsequent database LUW, you must make all of the database changes for the SAP LUW in a single database LUW. To maintain data integrity, you must bundle all of you database changes in the final database LUW of the SAP LUW.

Database LUW vs. SAP LUW

In the case of the database, an LUW is a sequence of data operations that cannot be divided up. The operations are either carried out in full or not at all. Database LUWs are modules that make up the database procedures for consistent data processing.

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 usually must include several database LUWs (see graphic 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).

In each database LUW, data is written to the database to special update tables (and not to the application tables). Once the dialog part has been completed, all of the data in a database LUW is transferred into the application tables: the update request is then performed.

Have a look at below link.

http://help.sap.com/saphelp_nw04/helpdata/en/41/7af4bfa79e11d1950f0000e82de14a/content.htm

[Former Member]

hi,

this gives complete idea

SAP LUW

Since, as a rule, an application program is processed by several work processes in succession, and every change of the work process is linked with an implicit database commit , an application program is not automatically linked with a single database LUW. This applies in particular to dialog-oriented applications, in which one database LUW is assigned to one dialog step.

To ensure the data consistency of application programs that are executed across different work processes, the application statements are not directly executed in an SAP LUW, rather, are first registered and then executed by a single work process, that is, in a single database LUW.

Two techniques are available for bundling the change statements in a database LUW:

Bundling via function modules (update)

Through the statement CALL FUNCTION...IN UPDATE TASK, an update function module is registered for subsequent execution in an update work process.

Bundling via function modules (transactional RFC)

Through the statement CALL FUNCTION... IN BACKGROUND TASK DESTINATION, a remote- compatible function module is registered for subsequent asynchronous execution via the RFC interface (transactional RFC ).

Bundling via subprograms

Through the statement PERFORM ... ON COMMIT, a subprogram is registered for subsequent execution in a different work process.

Statements for SAP LUWs

A SAP LUW is controlled via the Open SQL statements COMMIT WORK, ROLLBACK WORK and SET UPDATE TASK LOCAL.

Note

A function module can be classified either as an update function module or remote-compatible, but not both at the same time. The update helps realize SAP LUWs within an SAP System, while the transactional RFC creates LUWs in distributed systems.

COMMIT WORK

Variants:

1. COMMIT WORK [AND WAIT].

2. COMMIT CONNECTION con.

Effect

Terminates an SAP LUW and stores the changes.

Variant 1

COMMIT WORK [AND WAIT].

Effect

The statement COMMIT WORK completes the current SAP LUW and opens a new one, storing all change requests for the currenta SAP LUW in the process. In this case, COMMIT WORK performs the following actions:

It executes all subroutines registered using PERFORM ON COMMIT.

It triggers an internal event in Object Services that ensures the registration of changes in persistent objects as the last update function module, as well as the subsequent initialization of persistent object attributes.

It initiates the processing of all registered update function modules in the update work process.

This executes all high-priority update function modules registered using CALL FUNCTION ... IN UPDATE TASK in the order of their registration and in a common database LUW. If you do not specify the addition AND WAIT, the program does not wait until the update work process has executed it (asynchronous updating). If you specify the addition AND WAIT, however, program processing after COMMIT WORK will not continue until the update work process has executed the high-priority update function modules (synchronous updating).

If all high-priority update function modules are completed successfully, the statement executes the low-priority update function modules together in a common database LUW.

In parallel, it also executes the individual function modules registered using CALL FUNCTION ... IN BACKGROUND TASK DESTINATION in a separate database LUW for each destination.

It handles all SAP locks set in the current program according to the value of the formal parameter _SCOPE of the corresponding lock function modules.

It triggers a database commit that also terminates the current database LUW.

The completion of statement COMMIT WORK triggers the event TRANSACTION_FINISHED of the system class CL_SYSTEM_TRANSACTION_STATE, where the parameter KIND has the value of the constant CL_SYSTEM_TRANSACTION_STATE=>COMMIT_WORK.

If the statement COMMIT WORK is executed by calling special programs, be aware of the following:

In a program executed using batch input, or if you have called the program using the USING addition of the statement CALL TRANSACTION, COMMIT WORK terminates the batch input processing when using the corresponding settings.

In a program called using CALL DIALOG, COMMIT WORK initiates the processing of subroutines or updated function modules registered using PERFORM ... ON COMMIT and CALL FUNCTION ... IN UPDATE TASK. Therefore, it does not complete the current SAP LUW. The SAP LUW cannot be completed until you execute the COMMIT WORK statement in the calling program.

You cannot execute the COMMIT WORK statement during the updating procedure or during the execution of subroutines registered using PERFORM ... ON {COMMIT|ROLLBACK}.

System fields

sy-subrc Meaning

0 You have specified the AND WAIT addition, and the updating of the update function modules was successful.

4 You have specified the AND WAIT addition, and the updating of the update function modules was not successful.

The COMMIT WORK statement always sets sy-subrc to 0 if the AND WAIT addition is not specified.

Note

The COMMIT WORK statement closes all database cursors . Open SQL statements that access a database cursor later ( SELECT loop and FETCH) raise an exception that cannot be handled.

Variant 2

COMMIT CONNECTION con.

Note

This statement is for internal use only.

It cannot be used in application programs.

Effect

The COMMIT command is not executed on the standard database, but only on the secondary database connection specified by con. con is the name of the database connection as it was specified in the table DBCON in the column CON_NAME. The database connection con can also be specified dynamically in the form (source_text) - the source_text field contains the name of the database connection. The source_text field must be of the type C or STRING.

On the specified secondary database connection, the database commit:

Closes all open database cursors (OPEN CURSOR)

Releases all database locks

Note

Note that the COMMIT CONNECTION DEFAULT statement unlike COMMIT WORK executes a pure database commit on the DEFAULT connection.

Exceptions

Non-Catchable Exceptions

Cause: COMMIT WORK is not possible in a FORM that was called using PERFORM ... ON COMMIT.

Runtime Error: COMMIT_IN_PERFORM_ON_COMMIT

Cause: COMMIT WORK is not allowed in the update.

Runtime Error: COMMIT_IN_POSTING

ROLLBACK WORK

Variants:

1. ROLLBACK WORK.

2. ROLLBACK CONNECTION con.

Effect

Terminates a SAP-LUW without storing the changes.

Variant 1

ROLLBACK WORK.

Effect

The statement ROLLBACK WORK closes the current SAP-LUW and opens a new one. In doing so, all change requests of the current SAP-LUW are canceled. To do this, ROLLBACK WORK carries out the following actions:

Executes all subprograms registered with PERFORM ON ROLLBACK.

Deletes all subprograms registered with PERFORM ON COMMIT.

Raises an internal exception in the Object Services that makes sure that the attributes of persistent objects are initialised.

Deletes all update function modules registered with CALL FUNCTION ...IN UPDATE TASK from the VBLOG and deletes all transactional remote Function Calls registered with CALL FUNCTION ... IN BACKGROUND TASK from ARFCSSTATE and from ARFCSDATA.

Removal of all SAP locks set in the current program in which the formal parameter _SCOPE of the lock function module was set to the value 2.

Triggers a database rollback, which also ends the current database-LUW.

After completion of the statement COMMIT WORK, the event TRANSACTION_FINISHED of the system class CL_SYSTEM_TRANSACTION_STATE is raised, in which the parameter KIND has the value of the constant CL_SYSTEM_TRANSACTION_STATE=>ROLLBACK_WORK.

Variant 2

ROLLBACK CONNECTION con.

Note

This statement is for internal use only.

It cannot be used in application programs.

Effect

The ROLLBACK-statement is not executed on the standard database but only on the secondary database connection, specified through con. con is the name of the database connection as it was specified in table DBCON in column CON_NAME. The database connection con can also be specified dynamically in the form (source_text), in which the field source_text contains the name of the database connection. The field source_text must be of the type C or STRING.

Notes

As all opened database cursors on the respective database connections are closed at ROLLBACK, the attempt to continue a SELECT-loop after a ROLLBACK, leads to a runtime error. Due to the same reason, a FETCH after a ROLLBACK to the then closed cursor, leads to a runtime error. You have to make sure that cursors that are still open, are no longer used after ROLLBACK.

After execution of the statement ROLLBACK, SY-SUBRC is always equal to 0. It is not necessary to check if SY-SUBRC is unequal to 0 after ROLLBACK.

ROLLBACK must not be used during update (CALL FUNCTION ... IN UPDATE TASK) or during the execution of FORMs, which were registered with PERFORM ... ON COMMIT resp. PERFORM ...ON ROLLBACK.

The statement ROLLBACK WORK is implicitly executed if a message of the type A is treated with the addition ERROR_MESSAGE when calling a function module with CALL FUNCTION.

Exceptions

Non-Catchable Exceptions

Cause: ROLLBACK WORK is not allowed within a FORM that is called with PERFORM ... ON COMMIT or PERFORM ... ON ROLLBACK.

Runtime Error: ROLLBACK_IN_PERFORM_ON_COMMIT

Cause: ROLLBACK WORK is not allowed within an update.

Runtime Error: ROLLBACK_IN_POSTING

SET UPDATE TASK LOCAL

Syntax

SET UPDATE TASK LOCAL.

Effect

This statement specifies that the high-priority update function modules - registered during the current SAP LUW using CALL FUNCTION ... IN UPDATE TASK - are registered in the ABAP memory instead of the VBLOG database table. In addition, it specifies that the current work process and not the update work process run these modules during the current database LUW, when the COMMIT WORK statement is executed. This statement has no effect on low-priority update function modules.

At the beginning of every SAP LUW, the local update function is deactivated. If you wish to use it, you must reactivate it again before the first update function module is registered.

System fields

sy-subrc Meaning

0 The local update function is activated.

1 The local update function has not been activated, because the program has already registered at least one update function module for the normal updating procedure in the current SAP-LUW.

Notes

The local update function performs a synchronous update according to the COMMIT WORK statement, independent of the addition AND WAIT.

The occurrence of a database rollback during the local update affects all previous change requests.

<b>Pls reward if find useful</b>

[Former Member]

Hi pannati

Go through the following Link

http://help.sap.com

and find there

For Logical database

Logical Unit of Work (LUW)

A Logical Unit of Work (LUW or database transaction) is an inseparable sequence of database operations which must be executed either in its entirety or not at all. For the database system, it thus constitutes a unit.

LUWs help to guarantee database integrity. When an LUW has been successfully concluded, the database is once again in a correct state. If, however, an error occurs within an LUW, all database changes made since the beginning of the LUW are canceled and the database is then in the same state as before the LUW started.

An LUW begins

each time you start a transaction

when the database changes of the previous LUW have been confirmed (database commit) or

when the database changes of the previous LUW have been cancelled (database rollback)

An LUW ends

when the database changes have been confirmed (database commit) or

when the database changes have been canceled (database rollback)

Database commit and rollback

Within an LUW, database changes are not made until after a database commit. Prior to this, any database change can be canceled by a database rollback.

In the R/3 System, a database commit is triggered either automatically or by the ABAP/4 command COMMIT WORK or the appropriate Native SQL command for the database system.

Similarly, a database rollback is triggered either automatically or by the ABAP/4 command ROLLBACK WORK or the appropriate Native SQL command for the database system.

A database commit is triggered automatically by

each screen change, and especially after the ABAP/4 commands CALL SCREEN, CALL DIALOG, CALL TRANSACTION, MESSAGE or

a Remote Function Call

A database rollback is triggered automatically by

errors which occur at runtime or

the ABAP/4 command MESSAGE with the message type 'A'

After each database commit or rollback, the database locks set in the LUW are released (see Database Locking).

Thanks & regards

Abhishek Agrahari

[MichalKrawczyk]

Hi,

always the same logical unit of work

Regards,

michal