SAP NetWeaver AS ABAP Release 750, ©Copyright 2016 SAP AG. All rights reserved.
ABAP - Keyword Documentation →
ABAP - Reference →
Processing External Data →
Data Consistency →
Database LUW →
Isolation Levels
The term "isolation" refers to the separation of different transactions performed on the same data in a database. Different isolation levels specify how a database user can perform reads on the data of a different user modified in a
database LUW. The data is isolated by implementing appropriate
database locks.
The following isolation levels are significant in AS ABAP:
-
In uncommitted reads, every database user performing a read can see the modified data directly, not just the owner of the database LUW where the data was modified, even if no
database commit has been performed yet. The read is performed
without setting a shared lock (known as a dirty read), which means the existing exclusive lock is ignored
by the read. Data in a temporary state can, therefore, be read, even if it is to be removed again using a database rollback.
-
In committed reads, only the user of a database LUW has access to data modified in the LUW. Other database users cannot access the modified data before a
database commit is performed. In the case of reads, a shared
lock is set (not possible for the modified data due to the existing exclusive lock). Data can be accessed only when released by a database commit.
In an AS ABAP, the following settings apply to the isolation level:
- The SAP HANA database and Oracle databases support these isolation levels in their strictest form.
In the case of reads, they do not set a shared lock as in uncommitted reads,
but do read the data like in a committed read. If the data is locked in a different LUW by a write, the cached state of the data after the last database commit is accessed.
- Both isolation levels are possible on all other database with uncommitted
read being the default setting. The function module DB_SET_ISOLATION_LEVEL
can be used to set the isolation level to committed read. In the case
of reads, an attempt is actually made to set a shared lock, which can cause wait times. Calling the
function module DB_RESET_ISOLATION_TO_DEFAULT or the next database commit or rollback resets the isolation level to the default setting.
Many database systems employ additional isolation levels, such as serializable
and repeatable read. These work in a similar way to committed reads, but the shared lock is preserved until the next data object is read or until the
database cursor is closed. Since these isolation levels are not sufficiently standardized, they are not currently used in
AS ABAP.
Notes
- In databases that support the isolation levels committed read and
uncommitted read, the latter must be the default setting, since otherwise
deadlocks occur too quickly. There is no risk of this on SAP HANA databases and on Oracle databases.
These databases read the same data as in a committed read but do not set shared locks.
- When the database is accessed on AS ABAP, a database user is the same as a work process. This means
that, for the isolation level uncommitted read, a work process can perform
reads on data in a database LUW of the same or another user that has not yet been committed using a database commit.
- The isolation level does not modify how buffered tables
in Open SQL are accessed. The Committed Read level also accesses the
table buffer, which means that data can be old if it was modified on the database after the last buffer
synchronization. There is a guarantee, however, that data is only read if committed on the database
using a database commit. To make it possible to also access current data in a buffered data, the addition
BYPASSING BUFFER must be used in the Committed Read isolation level.