How commitment control works

 

Commitment control ensures that either the entire group of individual changes occurs on all systems that participate or that none of the changes occur.

For example, when you transfer funds from a savings to a checking account, more than one change occurs as a group. To you, this transfer seems like a single change. However, more than one change occurs to the database because both savings and checking accounts are updated. To keep both accounts accurate, either all the changes or none of the changes must occur to the checking and savings account.

Commitment control allows you to complete the following tasks:

• Ensure that all changes within a transaction are completed for all resources that are affected.

• Ensure that all changes within a transaction are removed if processing is interrupted.

• Remove changes that are made during a transaction when the application determines that a transaction is in error.

You can also design an application so that commitment control can restart the application if a job, an activation group within a job, or the system ends abnormally. With commitment control, you can have assurance that when the application starts again, no partial updates are in the database due to incomplete transactions from a prior failure.

 

Transaction

A transaction is a group of individual changes to objects on the system that appears as a single atomic change to the user.

iSeries™ Navigator uses the term transaction, whereas the character-based interface uses the term Logical Unit of Work (LUW). The two terms are interchangeable. This topic, unless specifically referring to the character-based interface, uses the term transaction.

A transaction can be any of the following situations:

• Inquiries in which no database file changes occur.

• Simple transactions that change one database file.

• Complex transactions that changes one or more database files.

• Complex transactions that change one or more database files, but these changes represent only a part of a logical group of transactions.

• Simple or complex transactions that involve database files at more than one location. The database files can be in one of the following situations:

  • On a single remote system.

  • On the local system and one or more remote systems.

  • Assigned to more than one journal on the local system. Each journal can be thought of as a local location.

• Simple or complex transactions on the local system that involve objects other than database files.

 

Parent topic:

Commitment control concepts