ADABAS provides various locking levels with respect to read consistency, specifically for each session: so-called isolation levels.
Isolation level 0 makes so-called "dirty reads" possible, i.e., the access to database objects that are just being modified by another user in an uncommitted transaction. Since no share locks are set implicitly, isolation level 0 allows the highest degree of parallel operation in OLTP operation. In order to compensate for the possible effects of a "dirty read", a check read should be done or the optimistic locks described below should be used.
For the isolation level 1 or 10, ADABAS implicitly sets a share lock on every table row currently being read, thus preventing access to modifications of transactions that have not yet been completed. This share lock is kept until the next read command for the same table is issued; i.e., for each table a share lock is set to one row at the most.
With respect to the handling of locks during the processing of mass commands, isolation level 15 is an extension of the isolation level 1 or 10. The tables addressed are locked in share mode for the duration of command processing. In this way, the tables involved cannot be modified while the commands are being processed.
For the isolation level 2 or 20, mass operations are first secured by a table share lock as in isolation level 15. In addition, all the rows read are locked in share mode. These locks are only released at the end of the transaction.
By implicitly setting table share locks on all tables processed up to the end of the transaction, the isolation level 3 or 30 ensures that database users only see those modifications they themselves have made.
By means of options in a SELECT statement, it is possible to work in a specific isolation level but to achieve a higher or lower read consistency with respect to multiuser effects.
In all isolation levels, updates of table rows lead to exclusive locks for these rows up to the end of the transaction.