In an Update request the data is changed for an entire SAP LUW (Logical Unit of Work), which are either carried out in full or not al all. An LUW can consist of multiple Transaction screens. So LUW can modify and update data consisting in multiple database objects (rows and tables), i.e. SAP’s LUW can result changes in many database objects. Sometimes only a few fields might be affected, so it might be required to lock only those affected fields, while rest of the fields can be used by other users. So therefore SAP has come out with its own Lock Concepts which can lock an object. An object in turn can lock a series of Database objects spread over many row and tables in the database level. Eg. When a User Master data is modified the data may affect more then one table in the Database Level, but Database can lock only at record level or a table level on one table. But SAP Locks will lock the entire object which could be spread over rows in all the affecting (here two) tables. The database lock exists only for the duration of the database LUW, in which the changes made in the SAP system are actually updated. And the SAP Lock is released once the LUW is commited or rolled back when the LUW is cancelled.
Why two different Enqueue Services for Java and ABAP.
Since SAP uses two separate schemas at the database, one each for ABAP and Java Stack. Data is saved is separately for ABAP and Java Stack. So enqueue process (locked objects) for Java would not interfere with the enqueue process (locked Objects) of ABAP stack.
