ABAP Keyword Documentation →  ABAP - Reference →  Processing External Data →  Data Consistency →  Database Locks 

Lock Conflicts in IBM DB2

With DB2 for i5/OS, locks are not only set for the changing transactions, but also for consistently reading buffered tables, cluster tables and pool tables. The isolation level "read stability" is used for this purpose in the database system, with the help of "shared locks", which prevent table contents from being changed simultaneously.

Besides timeouts and deadlocks, lock conflicts can also cause errors with DDL (data definition language) commands such as CREATE, ALTER and DROP, and slow down online reorganisation.

The OPEN CURSOR command with the WITH HOLD option can be used to maintain the position of a cursor beyond the commit period, if necessary.

To avoid lock conflicts, commits should be executed as database commits. Native SQL can be used for this, as shown below:

IF sy-dbsys = 'DB2'.
  EXEC SQL.
    COMMIT WORK
  ENDEXEC.
ENDIF.

We recommend that you use these database commits in programs with extremely long read operations.

Other versions: 7.31 | 7.40 | 7.54