SAP NetWeaver AS ABAP Release 751, ©Copyright 2017 SAP AG. All rights reserved.ABAP - Keyword Documentation → ABAP - Reference → Processing External Data → Data Consistency →
Any database permitting simultaneous access to multiple transactions requires database locks to manage and synchronize access. The tasks of this mechanism are to: This mechanism can be used to
The following sections are a short discussion of the properties of database locks:
Database systems do not usually provide commands for explicitly setting locks. Database locks are set implicitly each time data on the database is accessed. In ABAP, databases are accessed in the following ways:
Database systems set physical locks: All rows affected by a database call are locked. In the case of SELECT, these are the selected entries. In the case of UPDATE, DELETE, INSERT, and MODIFY, these are rows to be changed, deleted, or inserted.
The following call
for example, locks the entry in table SFLIGHT for Lufthansa flight 0400 on May 16, 1996.
It is not always the table row that is locked. Tables, data pages, and index pages can also be locked, for example. The units locked depend on the database system being used and the action being carried out.
In principle, one type of lock is enough to control competing data access. However, to allow a larger
number of transactions to run in parallel, database systems use a range of lock types. These can vary from system to system, but the following two examples outline sufficiently how locks work:
The current isolation level specifies whether the SQL command SELECT sets a shared lock.
If a transaction cannot lock an object because it is already locked by another transaction, it waits until the other transaction has released the lock. This can produce a deadlock. A deadlock occurs, for example, when two transactions are waiting for a lock held by the other.
A booking needs to be made in a flight reservation system for Lufthansa flight 0400 on May 16, 1996.
This is possible only if there are enough free seats. To prevent two bookings from being made at the
same time and avoid overbooking, the entry in the database table SFLIGHT
for this flight must be locked to prevent it from being changed by other transactions. This ensures
that the query to determine the number of free seats in the SEATSOCC field can be carried out, the flight
can be booked, and the SEATSOCC field can be updated by other transactions. The following program excerpt shows a solution for this problem:
The table row selected by SELECT SINGLE FOR UPDATE and inserted by INSERT is locked until the end of the database LUW. This prevents the flight from being overbooked and inconsistencies from occurring between tables SFLIGHT and SBOOK in the event of a database rollback after an error.
Database systems do not usually provide commands for explicitly releasing locks. All database locks are released no later than the next database commit or rollback. Shared locks usually have an even shorter lifetime. Sometimes, this causes problems for transactions that involve multiple dialog steps:
After the user has selected a flight in the above example, he or she usually performs further dialog steps to enter additional data for the reservation. Here, the flight reservation is added in a different database LUW than the original selection of the flight. Database locking does not prevent another transaction from booking this flight in the meantime, which can mean that the scheduled booking may have to be canceled after all.
From the point of view of the user, this solution is very inconvenient. To avoid this scenario, a flight reservation system must use the SAP locking mechanism to lock the flight for the entire duration of the transaction.