Choosing a CURRENTDATA option

The CURRENTDATA option of an application specifies whether data currency is required for read-only and ambiguous cursors when the ISOLATION(CS) option is used. This option enables a trade-off between the improved ability of multiple applications to access the same data concurrently and the risk that non-current data might be returned to the application.

About this task

Begin program-specific programming interface information.
Generally, the CURRENTDATA(NO) option increases the ability of multiple applications to access the same data concurrently. However, the trade off is an increased risk that non-current data might be returned to the application. The CURRENTDATA(YES) reduces the risk of non-current data being returned to the application. However, the trade off is a reduced ability for multiple applications to access the same data concurrently.

The CURRENTDATA bind option applies differently for applications that access local and remote data. For requests to remote systems, the CURRENTDATA has an effect for ambiguous cursors that use the following ISOLATION options: RR, RS, or CS. For access to a remote table or index, CURRENTDATA(YES) turns off block fetching for ambiguous cursors. The data returned with the cursor is current with the contents of the remote table or index for ambiguous cursors. Turning on block fetch offers best performance, but it means the cursor is not current with the base table at the remote site.

End program-specific programming interface information.

Procedure

For improved concurrent data access, use the following approaches:

  • Bind most applications with the ISOLATION(CS) and CURRENTDATA(NO) options. These options enable DB2® to release locks early and avoid taking locks in many cases. ISOLATION(CS) typically enables DB2 to release acquired locks as soon as possible. The CURRENTDATA(NO) typically enables DB2 to acquire the fewest number of locks, for better lock avoidance. When you use ISOLATION(CS) and CURRENTDATA(NO), consider using the SKIPUNCI subsystem parameter value to YES so that readers do not wait for the outcome of uncommitted inserts.
  • Commit work as soon as doing so is practical, to avoid unnecessary lock contention, even in read-only applications.