3. Planning Your Replication Scheme : Application Design Issues : Derived Information : Example: Avoiding Risks in Replicating Derived Data
 
Share this page                  
Example: Avoiding Risks in Replicating Derived Data
The potential risk of replicating derived data, as shown in the previous example, can be avoided if each branch maintains its own balance on its own local database, as shown in the following example.
The customer withdraws $50 from the account at Branch C. Data communications are disrupted to all other branches.
A
B
C
$100
$100
$50
Branch C queues the $50 transaction for replication to Branches A and B.
The customer withdraws $50 from Branch A. Branch A queues the $50 transaction for replication to Branches B and C. The transaction from A is replicated to B.
A
B
C
$50
$50
$50
The customer’s balance is now $50 in both Branches A and B. When the network comes up for Branch C, Branch A and B are informed of the $50 withdrawal that the customer made at Branch C. Branches A and B can update their balances. Branch A informs Branch C about the customer’s other $50 withdrawal transaction. All branches show the correct balance of $0.
A
B
C
$0
$0
$0
In this example, the transactions are replicated in the form of deposits and withdrawals. Because the balance is not being replicated, the replication does not collide on the balance table.