Lock Concept and Enqueue
Background <ul><li>Let us start with the legendary ATM example for transferring money from a Saving to Checking bank accou...
Database (implicit) LUW <ul><li>Is executed by the database system </li></ul><ul><li>Is a non-separable sequence of databa...
Why SAP LUWs? <ul><li>Every ABAP program that is currently active requires a work process, and each work process is logged...
Why SAP LUWs? (continued) <ul><li>The debit could get committed in the first work process’ database LUW and the credit cou...
SAP Architecture <ul><li>SAP Web Application Server  </li></ul>Work Processes beyond programmers control
 
SAP LUW Commands <ul><li>The following statement completes the current SAP LUW and opens a new one </li></ul><ul><ul><li>C...
Database Locks <ul><li>When accessing database using SQL, the database sets implicit physical database locks, these locks ...
SAP Locks <ul><li>They are based on lock objects that are defined in ABAP Dictionary </li></ul><ul><li>They permit locks o...
Creating SAP Locks <ul><li>Custom lock objects should start with E before the possible prefix of the customer namespace (Z...
ENQUEUE work process (server)  <ul><li>ENQUEUE work process (or the ENQUEUE logical server) manages the central lock table...
Lock Command <ul><li>CALL FUNCTION ‘ENQUEUE_EZ_RESERVATIONS’ </li></ul><ul><li>EXPORTING </li></ul><ul><li>  mode_reservat...
Buffering of Database Tables <ul><li>To decrease load on a database system, tables having many reads and few updates may b...
Upcoming SlideShare
Loading in...5
×

SAP ABAP Lock concept and enqueue

12,856

Published on

SAP ABAP Lock concept and enqueue

Published in: Technology, Business
2 Comments
6 Likes
Statistics
Notes
No Downloads
Views
Total Views
12,856
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
2
Likes
6
Embeds 0
No embeds

No notes for slide

SAP ABAP Lock concept and enqueue

  1. 1. Lock Concept and Enqueue
  2. 2. Background <ul><li>Let us start with the legendary ATM example for transferring money from a Saving to Checking bank account. Can anyone explain what this ATM example is? We very well know the need for having consistent data status before and after this bank transfer. </li></ul><ul><li>The Consistent Data Storage is usually done using the LUWs and Locks </li></ul><ul><ul><li>Logical Unit of Work (LUW) </li></ul></ul><ul><ul><ul><li>A LUW is a non-separable sequence of transactions (SQLs) that regulates the chronological transition from one consistent state to another, and usually ends with a database commit. </li></ul></ul></ul><ul><ul><li>Lock Concept </li></ul></ul><ul><ul><ul><li>Lock prevents unwanted access or update to data during an LUW. </li></ul></ul></ul><ul><li>LUWs are of two types </li></ul><ul><ul><li>Database (implicit) </li></ul></ul><ul><ul><li>ABAP (explicit) </li></ul></ul><ul><li>LOCKS are also of two types </li></ul><ul><ul><li>Database Locks </li></ul></ul><ul><ul><li>SAP Locks </li></ul></ul>
  3. 3. Database (implicit) LUW <ul><li>Is executed by the database system </li></ul><ul><li>Is a non-separable sequence of database operations that end in a database commit </li></ul><ul><li>Is either executed completely by the database (commit) or not executed at all (rollback) </li></ul><ul><li>When completed, returns the system to consistent status and a new database LUW is opened </li></ul><ul><li>Is normally not sufficient for consistent data storage in SAP environment (why? see next slide) </li></ul>Database LUW Program starts Program ends Commit or Rollback update, delete etc **This is for NON SAP Environment – see subsequent slides for SAP Environment **
  4. 4. Why SAP LUWs? <ul><li>Every ABAP program that is currently active requires a work process, and each work process is logged on to the database as a user and starts/end a database LUW </li></ul><ul><li>A work process cannot execute more than one database LUW in parallel </li></ul><ul><li>More than one work process cannot influence a single database LUW </li></ul><ul><li>An ABAP program (among other reasons, including the scheduling algorithm used or waiting for a resource) can be rolled out of the work process to make space for other waiting processes </li></ul><ul><li>Therefore an ABAP program is frequently linked with more than one work process over the course of its total runtime </li></ul><ul><li>In our ATM example the debit and credit statements of the accounts could happen to be in different work process. But as mentioned two or more work processes cannot influence a single database LUW </li></ul>
  5. 5. Why SAP LUWs? (continued) <ul><li>The debit could get committed in the first work process’ database LUW and the credit could get committed in the next work process database LUW </li></ul><ul><li>But, if the second work process fails for some reason, it will be too late to undo the first as would have already been committed by then </li></ul><ul><li>Therefore, in SAP environment it is not sufficient for consistent data storage by just relaying on the database LUW </li></ul><ul><li>For a program that extends over several work process and therefore several database LUWs (and most of them do), the changes should not be committed until the program ends. This functionality is provided by the SAP LUWs </li></ul><ul><li>The database LUWs are generally bundled and then executed as a single database LUWs during the final work process of the SAP LUW. </li></ul>
  6. 6. SAP Architecture <ul><li>SAP Web Application Server </li></ul>Work Processes beyond programmers control
  7. 8. SAP LUW Commands <ul><li>The following statement completes the current SAP LUW and opens a new one </li></ul><ul><ul><li>COMMIT WORK [AND WAIT] </li></ul></ul><ul><li>The [AND WAIT] clause makes the process synchronous (waits for completion of commit) before continuing with the rest of the program </li></ul><ul><li>The following command ends a LUW without saving changes </li></ul><ul><ul><li>SAP ROLLBACK </li></ul></ul>
  8. 9. Database Locks <ul><li>When accessing database using SQL, the database sets implicit physical database locks, these locks remain until the database LUW. The modifying statements INSERT, UPDATE, MODIFY and DELETE and the SELECT with the FOR UPDATE clause setup the exclusive locks. </li></ul><ul><li>These implicit database locks do not suffice for setting SAP LUW locks. SAP locks are used for this purpose. </li></ul>
  9. 10. SAP Locks <ul><li>They are based on lock objects that are defined in ABAP Dictionary </li></ul><ul><li>They permit locks of single or several rows of a single database table </li></ul><ul><li>They also permit locks of rows of several database tables linked by foreign key dependencies </li></ul><ul><li>SAP locks must be enabled for the duration of SAP LUWs. Therefore various work processes, and if applicable, changing application servers must be able to handle these locks </li></ul><ul><li>If a database table is used in various transactions make sure SAP locks are used in critical data select and update areas to avoid data been overwritten by different transactions - all running the same time </li></ul><ul><li>If you think a SAP lock is not required because the database table you are using is being used by just one transaction, think again. Two or more users using the same transaction and data could be overwriting each others committed data </li></ul><ul><li>Not able to reproduce any production data error that occurs occasionally? The problem could be the lack of SAP locks in your application design! </li></ul>
  10. 11. Creating SAP Locks <ul><li>Custom lock objects should start with E before the possible prefix of the customer namespace (Z). [Example: EZ_RESERVATIONS] </li></ul><ul><li>The creation of lock object generates two lock function modules whose names consist of the prefixes ENQUEUE_ and DEQUEUE_ and the name of the lock object [Example: ENQUEUE_EZ_RESERVATIONS & DEQUEUE_EZ_RESERVATIONS] </li></ul><ul><li>The Lock Parameter that is setup include the key fields of the table for which (key) values can be passed when the function module is called </li></ul><ul><li>The ENQUEUE_<lockobject> sets an SAP lock by writing entries into the central lock table </li></ul><ul><li>Parameter passing can inform the function module whether a READ or WRITE lock should be set </li></ul><ul><li>If a READ lock set by a program, no other program can set the WRITE lock, however additional READ locks can be set </li></ul><ul><li>To check whether a LOCK is set, simply try to lock and object. Exception implies that lock has already been set by another program. </li></ul>
  11. 12. ENQUEUE work process (server) <ul><li>ENQUEUE work process (or the ENQUEUE logical server) manages the central lock table of the entire system in its memory. The function modules to set and delete locks are executed in this work process </li></ul><ul><li>A SAP installation can contain only one application server with an ENQUEUE work process </li></ul><ul><li>If we have multiple application servers environment, various program running in various application servers including the one that has the ENQUEUE work process need to communicate with this central area to set and delete locks </li></ul><ul><li>Transaction SM12 – show current locks in the system </li></ul>
  12. 13. Lock Command <ul><li>CALL FUNCTION ‘ENQUEUE_EZ_RESERVATIONS’ </li></ul><ul><li>EXPORTING </li></ul><ul><li> mode_reservations = ‘X’ </li></ul><ul><li> reservation_id = p_resid </li></ul><ul><li>EXCEPTION </li></ul><ul><li> foreign_lock = 1 </li></ul><ul><li> system_failure = 2 </li></ul><ul><li> OTHERS = 3. </li></ul><ul><li>mode_reservations = ‘X’ implies WRITE lock </li></ul><ul><li>Unlock command works similarly using the DEQUEUE_EZ_RESERVATIONS function. </li></ul>
  13. 14. Buffering of Database Tables <ul><li>To decrease load on a database system, tables having many reads and few updates may be buffered. </li></ul><ul><li>In SAP Buffering, buffering occurs (resides) in the shared memory of the current application server. </li></ul><ul><li>When a table is defined, buffering attributes are setup by the developer depending on the table usage. </li></ul><ul><li>Synchronization between the various buffers (of various application servers) and the database is controlled by SAP’s database interface. </li></ul><ul><li>Buffering improves the performance dramatically by a factor of 50 to 500 in some cases. </li></ul><ul><li>Buffered table’s data may not be available to other applications for up to 60 seconds, so tables that are updated regularly should not be buffered. </li></ul><ul><li>Buffering is bypassed implicitly by number of variants of SQL statements (distinct clause/aggregate functions/joins/order by/etc) </li></ul><ul><li>Buffered data is bypassed by explicitly by using the BYPASS BUFFER clause so that database data can be accessed. </li></ul>

×