Contention can occur when the Capture and Apply programs try to access the same table on DB2 platforms that do not support ISOLATION (UR).
To minimize contention:
Change data tables and UOW tables can be held for a long time; they can be locked in two ways: global locks or a single LOCK TABLE. The first is a global lock, which is a lock against the global critical section table. A single LOCK TABLE, obtained before the table is accessed, is issued.
The Capture program gets the critical section lock in exclusive mode before it starts capturing changes. During this time, the Apply program cannot access those tables; the Apply program must get the critical section lock in shared mode. After this sequence of change captures (that is, after a scheduled COMMIT), the Capture program becomes inactive, allowing one or more Apply program processes to get the lock in shared mode.
You can decrease the COMMIT_INTERVAL in the tuning parameters table; this forces the Capture program to give up the lock more often, giving the Apply program the opportunity to access the change data table. If you decrease the COMMIT_INTERVAL value to less than 20 seconds while using automatic pruning, you also increase the frequency of pruning while slowing performance.
The benefit of trying to make change data available to the Apply program immediately is outweighed by the increased chance of contention between the Capture and Apply programs.