ABAP Keyword Documentation → ABAP - Reference → Processing External Data → Data Consistency
Database Locks
Any database permitting simultaneous access to multiple transactions requires database locks to manage and synchronize access. The tasks of this mechanism are to:
- Protect data objects currently being changed or read by a transaction from being changed by other transactions at the same time
- Protect a transaction from reading data objects that have not yet been committed by another transaction
The following sections are a short discussion of the properties of database locks:
Other versions: 7.31 | 7.40 | 7.54
Setting and Releasing Locks
implicitly
Locked Objects
physical
The following call
WHERE
CARRID = 'LH' AND
CONNID = '0400' AND
FLDATE = '19960516'
INTO ... .
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.
Lock Mode
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:
- Shared lock
Shared locks allow the system to set other shared locks, but prevent other transactions from setting exclusive locks for the objects in question.
- Exclusive lock
Exclusive locks do not allow other transactions to set any locks for the objects in question.
Exclusive locks are set by the Open SQL statements
SELECT SINGLE FOR UPDATE, INSERT,
UPDATE,
MODIFY, and DELETE (or by the appropriate Native SQL statements).
The isolation level of the transaction is responsible
for determining whether the Open SQL command SELECT (or the corresponding Native SQL command) sets a shared lock.
- The following settings are possible in all databases except the SAP HANA database and Oracle databases:
- Uncommitted reads (the default setting) do not attempt to set shared locks. Data is also read that is not protected by an exclusive lock and not yet committed using a database commit.
- Committed reads (which can be configured using the function module DB_SET_ISOLATION_LEVEL) set a shared lock during the read and then remove it again. This is possible only when exclusive locks do not exist, which can entail wait times.
- The SAP HANA database and Oracle databases do not set shared locks, but also only read data committed by a database commit.
deadlock
Example
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:
SELECT SINGLE FOR UPDATE *
FROM sflight
WHERE
carrid = 'LH' AND
connid = '0400' AND
fldate = '19960516'
INTO @sflight_wa.
IF sy-subrc <> 0.
MESSAGE e...
ENDIF.
IF sflight_wa-seatsocc < sflight_wa-seatsmax.
sbook_wa-carrid = 'LH'.
sbook_wa-connid = '0400'.
sbook_wa-fldate = '19960516'.
...
INSERT sbook FROM sbook_wa.
IF sy-subrc <> 0.
MESSAGE e...
ENDIF.
UPDATE sflight
SET
seatsocc = seatsocc + 1
WHERE
carrid = 'LH' AND
connid = '0400' AND
fldate = '19960516'.
ELSE.
MESSAGE e...
ENDIF.
COMMIT WORK.
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.
Lock Duration
All database locks are released no later than the next database commit or rollback. Shared locks usually have s 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 user's point of view, 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.