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.
Note: 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.
Note: 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.
Note: 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: - If the wait time exceeds 60 seconds, inquiry message CPA8351 is sent to
ask the user whether to continue waiting or cancel the operation.
- 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.