The index locking situation has been improved with type 2 indexes, but old type 1 indexes must be explicitly converted on indexes previously created before version 8.

Frequently, people mix the concept of deadlock and timeout, when they are actually not the same. A deadlock (as described by ARWinner) would theoretically NEVER be resolved except when the database manager detects the probable deadlock, and then cancels one of the processes.

An ordinary timeout due contention can occur when a process is waiting for a lock to be released by another process, but the defined wait period has been exceeded, and the process is then cancelled. In theory, if there was no wait period defined (or it was long enough), the process eventually would be able to continue when the other process finished.

As discussed in recent threads on this forum, lock escalation can cause row locks to be escalated to tables level locks, which causes contention with other processes. See the other recent threads (about 1-2 weeks ago) for a discussion on how to deal with this.

Also, you can use cursor stability (CS) isolation level (defined in the program or the bind option) to increase concurrency. Usually the default isolation level is repeatable read (RR), but the default can be changed. You might consider changing the default isolation level to read stability (RS) and have certain programs override it by using CS. Frequent commits also help.

However, increasing concurrency and preventing lock escalation to table level, may increase the amount of work DB2 does in maintaining row level locks. Obviously, in many cases, the extra workload is necessary to have adequate concurrency.