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:
- Uncommitted read
- Committed read
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.
7.31 | 7.40 | 7.54
- 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.