Commitment control is a function that allows you to define and
process a group of changes to resources, such as database files or tables,
as a transaction.
Commitment control ensures that either the entire group of individual changes
occur 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:
- 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.
Note: 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:
- 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.