So far, we were considering cases where the transaction scope was limited on a single database. If we take the example of account A and B, our implicit assumption was that the accounts are managed on a single database, say, a specific bank's database. In reality, we have multiple banks in the market, and for good reasons, account A and B can belong to two different banks. However, such transactions like transferring 500 bucks from account A to account B will still be a valid business requirement.
So, now, our problem specification has been changed to "log changes to both databases, or roll back from both". Such a transaction is commonly defined as Distributed Transaction, as the scope of the transaction is now spread on more than one databases.
As long as the scope of a transaction remains within a single database, transaction can be controlled using Transaction Control SQL statements such as Commit or Rollback. When the transaction spreads across databases, such database level controls can no longer be enforced. To manage such distributed transactions we need a Distributed Transaction Manager, a generation ahead of Transaction Manager.
