Optimizing performance for commitment control

 

Using commitment control requires resources that can affect system performance. Several factors affect system performance regarding commitment control.

 

Factor that does not affect performance

Open a file

If you open a file without specifying the commit open option, no additional system resource is used even if a commitment definition has been started. For more information about specifying the commit open option, see the appropriate high-level language reference manual.

 

Factors that degrade performance

Journal

Journaling a file requires system resources. However, in most cases journaling performs better with commitment control than without commitment control. If you specify only after-images, commitment control changes this to both before-images and after-images while commitment control is in effect. Typically this is a space, not a performance, consideration.

Commit operation

If any changes were made to journaled resources during the transaction, each commit of a transaction adds two entries to each journal related to those resources. The number of entries added can increase significantly for a large volume of small transactions. You might want to place the journal receivers in a separate disk pool from the journals.

Rollback operation

Because commitment control must roll back the pending changes recorded in the database, additional system resources are required whenever a rollback occurs. Also, if record changes are pending, a rollback operation causes additional entries to be added to the journal.

Start Commitment Control (STRCMTCTL) and End Commitment Control (ENDCMTCTL) commands

Additional overhead is incurred by the system each time a commitment definition is started using the STRCMTCTL command and is ended using the ENDCMTCTL command. Avoid using the STRCMTCTL and ENDCMTCTL commands for each transaction. Use them only when necessary. You can establish a commitment definition at the beginning of an interactive job and use it for the duration of the job.

Use more than one journal for commitment control transactions

With two-phase commit, files that are opened under commitment control can be journaled to more than one journal. However, using more than one journal takes additional system resources to manage the commitment definition. Using more than one journal can also make recovery more complicated.

Record locking

Record locking can affect other applications. The number of records locked within a particular job increases the overall system resources used for the job. Applications needing to access the same record must wait for the transaction to end.

Request SEQONLY(*YES)

If you request the SEQONLY(*YES) option (by using the OVRDBF command or the application program implicitly attempts to use SEQONLY(*YES)) and the file is opened for input only under commitment control with LCKLVL(*ALL), the option is changed to SEQONLY(*NO). This option can affect the performance of input files because records will not be blocked.

Request a record-level change for a database file when save-while-active processing is active

A request to make a record-level change under commitment control for a database file might be delayed if the commitment definition is at a commitment boundary and a save-while-active operation is running in a different job. This can happen when a file is journaled to the same journal as some of the objects on the save request.

The Status column on the Work with Active Jobs (WRKACTJOB command) display shows CMTW (commit wait) when a job is being held due to save-while-active checkpoint processing.

Commit or roll back changes when save-while-active processing is active

A commit or rollback operation might be delayed at a commitment boundary when a save-while-active operation is running in a different job. This can happen when an API commitment resource was previously added to the commitment definition, unless the API resource was added using the QTNADDCR API and the Allow normal save processing field has a value of Y.

Because the job is held during the commit or rollback request, and because a commit or rollback request can be performed only for a single commitment definition at a time, jobs with more than one commitment definition with API commitment resources added can prevent a save-while-active operation from completing.

If you use the new save with partial transactions feature the object can be saved without ending a commitment definition.

Request an object-level change when save-while-active processing is active

A request to make an object-level change under commitment control might be delayed if the commitment definition is at a commitment boundary and a save-while-active operation is running in a different job. This can happen when an object-level change is made while the save-while-active operation is running against the library the object is in. For example, the create SQL table operation under commitment control for table MYTBL in library MYSQLLIB might be delayed when a save-while-active operation is running against library MYSQLLIB.

If the wait time exceeds 60 seconds, inquiry message CPA8351 is sent to ask the user whether to continue waiting or cancel the operation.

Add an API resource using the QTNADDCR API

A request to add an API commitment resource using the QTNADDCR API might be delayed if all commitment definitions for the job are at a commitment boundary and a save-while-active operation is running in a different job.Notes:

  1. If the wait time exceeds 60 seconds, inquiry message CPA8351 is sent to ask the user whether to continue waiting or cancel the operation.

  2. This does not apply to API resources that were added using the QTNADDCR API if the Allow normal save processing field has a value of Y.

 

Factors that improve performance

Use a default journal

Using a default journal can help performance if you close and reopen all files under commitment control while the commitment definition is active. However, using a default journal with OMTJRNE(*NONE) degrades the performance of commit and rollback operations.

Select a last agent

Performance is enhanced when a last agent is selected because fewer interactions between the system and the last agent are required during a commit operation. However, if a communications failure occurs during a commit operation, the commit operation will not complete until resynchronization completes, regardless of the value of the wait for outcome option. Such a failure is rare but this option allows the application writer to consider the negative impact of causing the user to wait indefinitely for the resynchronization to complete when a failure does occur. Weigh this against the performance enhancement that is provided by last agent optimization during successful commit operations. This consideration is generally more significant for interactive jobs than for batch jobs.

The default is that a last agent is permitted to be selected by the system but the user can modify this value using the QTNCHGCO API.

Not use the wait for outcome option

When remote resources are under commitment control, performance is improved when the Wait for Outcome option is set to N (No) and all remote systems support presumed abort. The Wait for Outcome option is set to N by the system for DRDA® and DDM application when the first connection is made to a remote system. APPC applications must explicitly set the Wait for Outcome option, or the default value of Y will be used.

Select the OK to Leave Out option

Performance is improved when the OK to Leave Out option is selected.

Select the Vote Read Only option

Performance is improved when the Vote Read Only option is selected.

 

Parent topic:

Managing transactions and commitment control

 

Related concepts


Journal management
Commitment definition for two-phase commit: Indicate OK to leave out
Commitment definition for two-phase commit: Allow vote read-only