Select a stringent level of commitment control

Do not use commitment control unnecessarily. The overhead that is associated with locking not only increases utilization, but also reduces concurrency. However, if your application is not read-only, commitment control may be required.

A common alternative is to use optimistic locking. Optimistic locking involves issuing explicit UPDATEs by using a WHERE clause that uniquely determines a particular record. Optimistic locking ensures that the record does not change after it is retrieved.

Many third-party tools use this approach, which is why they often require a unique index to be defined for updatable tables. This allows the record update to be made by fully qualifying the entire record contents. Consider the following example:

   UPDATE table SET C1=new_val1, C2=new_val2, C2=new_val3
      WHERE C1=old_val1 AND C2=old_val2 AND C3=old_val3

This statement would guarantee that the desired row is accurately updated, but only if the table contained only three columns, and each row was unique. A better-performing alternative would be:

   UPDATE table SET C1=new_val1, C2=new_val2, C3=CURRENT_TIMESTAMP
      WHERE C3=old_timestamp

This only works, however, if the table has a timestamp column that holds information on when the record was last updated. Set the new value for this column to CURRENT_TIMESTAMP to guarantee row uniqueness.

Note: This technique does not work with any object model that uses automation data types (for example, Visual Basic, Delphi, scripting languages). The variant DATE data type has a timestamp precision of approximately one millisecond. The iSeries™ server timestamp is either truncated or rounded off, and the WHERE clause fails.

If commitment control is required, use the lowest level of record locking possible. For example, use *CHG: over *CS when possible, and never use *ALL when *CS provides what you require.