Filter
Top Products
Product Environment 9-53
Determining Database Consistency
Step 2: Determine If the Networked Database Contains Inconsistent
Data
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?
A transaction that is inconsistently implemented causes problems whenever
the piece of work rolled back by one participant is dependent on a piece of
work that was updated by another participant. It is impossible to define these
dependencies with SQL 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.
Before proceeding 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
Verify also that every participant OnLine that is assumed to have committed
the transaction actually modified data. It might be that a read-only OnLine is
listed as a participant that committed a transaction.
If an inconsistent transaction does not lead to a violation of data integrity, you
can quit the procedure at this point.