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:

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