Product Environment 9-53
Determining Database Consistency
Step 2: Determine If the Networked Database Contains InconsistentData
Suppose that you have determined that a transaction was inconsistently
implemented and that one or more participants committed the transaction
while one or more participants rolled it back. What does this mean to your
networked database system? When does this cause problems with data
integrity?
Atransaction that is inconsistently implemented causes problems whenever
the piece of work rolled back by one participant is dependent on a piece of
workthat was updated by another participant. It is impossible to define these
dependencies withSQL because distributed transactions do not support
constraints that reference data at multiple database servers. The pieces of
work are independent (no dependencies exist) only if the data could have
been updated in two independent transactions. Otherwise, the pieces of
work are considered to be dependent.
Beforeproceeding any further, consider the transaction that caused the error.
Are the pieces of data that were updated and rolled back dependent on one
another? Multiple updates might be included in a single transaction for
reasons other than maintaining data integrity. For example, here are three
possible reasons:
■Reduced transaction overhead
■Simplified coding
■Programmer preference
Verifyalso that every participant OnLine that is assumed to have committed
thetransaction actually modified data. It might be that a read-only OnLine is
listed as a participant that committed a transaction.
Ifan inconsistent transaction does not lead to a violation of data integrity,you
can quit the procedure at this point.