LUW

[Former Member]

Hi

What s the difference between SAP LUW and DB LUW?

Regards

Aruthra

[Former Member]

LUW,

two types:

1.SAP LUW----COMMIT AT THE END OF TRANSACTION

2.DB LUW------COMMIT AFTER EVERY SCREEN

LUW AND ITS TYPES CAN BE OBTAINED FROM THE LINKS GIVEN

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

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

[Former Member]

hi,

<b>Database LUW vs. SAP LUW</b>

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 which go to make up the database procedures for consistent data processing. An R/3 transaction can include several database LUWs (see example above), each of which can be terminated with a database COMMIT, which is generated automatically.

By way of contrast, an LUW for the R/3 System is a business process, which cannot be divided up. The process is either executed in full or not at all. The SAP LUW of an R/3 transaction usually has to contain several database LUWs. Under normal circumstances, it contains a dialog transaction (which maps a business process), and the command for writing the data to the database (update).

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

<b>REWARD IF USEFUL AND CLOSE THIS THREAD..</b>

[Former Member]

HI

SAP LUW

Die Verbuchungsverwaltung

The Open SQL statements INSERT, UPDATE, MODIFY, and DELETE allow you to program database changes that extend over several dialog steps. Even if you have not explicitly programmed a database commit, the implicit database commit that occurs after a screen has been processed concludes the database LUW.

Under this procedure, you cannot roll back the database changes from previous dialog steps. It is therefore only suitable for programs in which there is no logical relationship between the individual dialog steps.

However, the database changes in individual dialog steps normally depend on those in other dialog steps, and must therefore all be executed or rolled back together. These dependent database changes form logical units, and can be grouped into a single database LUW using the bundling techniques listed below.

DB LUW=>

a system has only one user inserting or changing data, there is obviously no consistency problem. Parallel processing by multiple users is another matter. Often several data changes are necessary to perform a single business operation. Technically speaking, these changes have to be done within a single logical unit of work (LUW). In this case, you can only guarantee data consistency by locking changed data until the end of the LUW to prevent interference from parallel processes.

Because of these locks, true parallel processing is not possible. However, users don't notice the difference between simultaneous and almost simultaneous response if the difference is much smaller than the total time needed to fulfill a certain task. Thus, exclusive locks on central objects must be kept only for a short time. Only data objects vital for consistency should be locked.

You can find the LUW concept implemented in all relational databases. Each data change locks the affected data record until a database commit signals the end of the LUW. In an R/3 environment, each dialog step of a user session results in a database commit, which is necessary to let other users access the dialog workprocess during this user's think time. Because of this fact, database locks cannot be held over several dialog steps.

Besides the database LUW, there are SAP LUWs within which SAP enqueues ensure data consistency across multiple dialog steps. Figure 3 illustrates the difference between a DB LUW and an SAP LUW. While SAP enqueues are necessary in many cases, they can reduce the scalability of a process dramatically because the length of time an enqueue is held depends on the user's think time.

R/3's handling of enqueues offers greater flexibility than its handling of database locks. An application can set and release both shared and exclusive enqueues at any time. In general, an SAP LUW consists of multiple dialog steps plus an update step. The ABAP statement COMMIT WORK passes ownership of the enqueues from the dialog workprocess to an update workprocess. The application program releases all enqueues and database locks at the end of the update step.

There is no one-to-one relationship between an enqueue object and a database table. In principle, enqueues can protect objects that consist of several records in different tables as well as those consisting of only a couple of fields within one record. Because all programs that rely on a consistent read of such objects must actively check enqueues, all developers accessing the information must understand and implement the enqueue scheme layout. You can find the SAP enqueue objects defined in the ABAP dictionary. For each object, two function modules are automatically created to enable enqueue and dequeue operations.

You should set exclusive locks as late as possible (for example, late locks in materials movements) and release them as early as possible (for example, locks of material sets during availability check). Reduced locking time means increased overall processing time because it entails converting exclusive locks into shared locks or rereading data to guarantee consistency without a lock. Even when the business process you want to implement doesn't require this rather complicated lock handling to achieve the necessary scalability, you should always keep the following guidelines in mind:

Shift database-locking accesses to the update task. Encapsulate the database lock statements in function modules called with the code addition IN UPDATE TASK. When the program executes COMMIT WORK, all function modules called with this addition are passed together with the interface's input parameters to a separate workprocess - the update task - for execution. Thus, the database locking accesses are separated from the user's dialog steps. This not only improves the (dialog) response times of the application, but also ensures a one-to-one relationship between a database LUW and a SAP LUW spanning more than one dialog step.

Updates processed directly from the dialog part would cause the SAP LUW to be split into several database LUWs. This split has no noticeable effect as long as the transaction is completed without any problems. However, it can lead to data corruption when problems occur; therefore, it is essential that any data updated by custom code extensions (for example, user exits) must follow the same conventions and use the update task.

I HOPE THIS WILL HELP YOU TO SOLVE YOUR PROBLEM

THANKS

MRUTYUNJAYA TRIPATHY