Concurrency

This ability is automatically supplied by the DB2^® UDB for iSeries™ database manager. Locks are implicitly acquired on tables and rows to protect concurrent users from changing the same data at precisely the same time.

Typically, DB2 UDB for iSeries will acquire locks on rows to ensure integrity. However, some situations require DB2 UDB for iSeries to acquire a more exclusive table level lock instead of row locks.

For example, an update (exclusive) lock on a row currently held by one cursor can be acquired by another cursor in the same program (or in a DELETE or UPDATE statement not associated with the cursor). This will prevent a positioned UPDATE or positioned DELETE statement that references the first cursor until another FETCH is performed. A read (shared no-update) lock on a row currently held by one cursor will not prevent another cursor in the same program (or DELETE or UPDATE statement) from acquiring a lock on the same row.

Default and user-specifiable lock-wait time-out values are supported. DB2 UDB for iSeries creates tables, views, and indexes with the default record wait time (60 seconds) and the default file wait time (*IMMED). This lock wait time is used for DML statements. You can change these values by using the CL commands Change Physical File (CHGPF), Change Logical File (CHGLF), and Override Database File (OVRDBF).

The lock wait time used for all DDL statements and the LOCK TABLE statement, is the job default wait time (DFTWAIT). You can change this value by using the CL commands Change Job (CHGJOB) or Change Class (CHGCLS).

In the event that a large record wait time is specified, deadlock detection is provided. For example, assume one job has an exclusive lock on row 1 and another job has an exclusive lock on row 2. If the first job attempts to lock row 2, it will wait because the second job is holding the lock. If the second job then attempts to lock row 1, DB2 UDB for iSeries will detect that the two jobs are in a deadlock and an error will be returned to the second job.

You can explicitly prevent other users from using a table at the same time by using the SQL LOCK TABLE statement. Using COMMIT(*RR) will also prevent other users from using a table during a unit of work.

In order to improve performance, DB2 UDB for iSeries will frequently leave the open data path (ODP) open. This performance feature also leaves a lock on tables referenced by the ODP, but does not leave any locks on rows. A lock left on a table may prevent another job from performing an operation on that table. In most cases, however, DB2 UDB for iSeries will detect that other jobs are holding locks and events will be signalled to those jobs. The event causes DB2 UDB for iSeries to close any ODPs (and release the table locks) that are associated with that table and are currently only open for performance reasons. Note that the lock wait time out must be large enough for the events to be signalled and the other jobs to close the ODPs or an error will be returned.

Unless the LOCK TABLE statement is used to acquire table locks, or either COMMIT(*ALL) or COMMIT(*RR) is used, data which has been read by one job can be immediately changed by another job. Typically, the data that is read at the time the SQL statement is executed and therefore it is very current (for example, during FETCH). In the following cases, however, data is read before the execution of the SQL statement and therefore the data may not be current (for example, during OPEN).

• ALWCPYDTA(*OPTIMIZE) was specified and the optimizer determined that making a copy of the data performs better than not making a copy.
• Some queries require the database manager to create a temporary result table. The data in the temporary result table will not reflect changes made after the cursor was opened. A temporary result table is required when:
  • The total length in bytes of storage for the columns specified in an ORDER BY clause exceeds 2000 bytes.
  • ORDER BY and GROUP BY clauses specify different columns or columns in a different order.
  • UNION or DISTINCT clauses are specified.
  • ORDER BY or GROUP BY clauses specify columns which are not all from the same table.
  • Joining a logical file defined by the JOINDFT data definition specifications (DDS) keyword with another file.
  • Joining or specifying GROUP BY on a logical file which is based on multiple database file members.
  • The query contains a join in which at least one of the files is a view which contains a GROUP BY clause.
  • The query contains a GROUP BY clause which references a view that contains a GROUP BY clause.
• A basic subquery is evaluated when the query is opened.