Transaction Handling
From RemObjects Software
This is a Data Abstract Architecture entry
Feel free to add your notes to this topic below.
Most modern databases provide support for transactions, to group several data modifications into one atomic action. An entire transaction either completes 100% successfully, or fails entirely, thus making sure that the database is not never left in an inconsistent state.
As the classic example, consider a database handling money transfers within a bank. To transfer money from one account to another, the database would reduce the balance for one account, and increase the balance for the other. For any one of these actions to fail on its own would be catastrophic, as money would have been lost (deducted from one but not credited to the other account), or duplicated (credited to the new but not deducted from the original account).
By wrapping the two database actions into a single transaction, the database engine ensures that one of two possible outcomes: either both actions succeed, or both actions fail.
In the first case, the transaction would be considered Commited, the changes having been applied to the database. In the second case, the transaction would be Rolled Back, and all changes (including those that succeeded on their own) have been discarded. As far as the database is concerned, a rolled back transaction simply never happened.
Transactions in Data Abstract
Like all other aspects of data access, Data Abstract encapsulates transactions in a database-agnostic way, so that transaction-based code will work against all databases that support them.
When working directly with the low-level IAbstractConnection/IDAConnection objects, methods are provided to begin, commit and roll back transactions, as needed.
The DataAbstractService/TDataAbstractService classes automatically apply transactions when applying changes from clients back to the server, making sure that transactions are committed or rolled back as needed, depending on whether updates succeeded. They also provide events that allow you to take more explicit control over transactions, including beginning/committing/rolling them back on your own, as needed.
See Also
- IAbstractConnection/IDAConnection interfaces
- IDAIBTransactionAccess interface (Delphi)
- DataAbstractService/TDataAbstractService
- Lists
Product: RemObjects Data Abstract
Current version: Data Abstract 'Vinci' (5.0)
Lists — Glossary — Features — How To — Drivers — Components — Tools — Samples — Articles — Architecture — Issues
Categories: Index | Data Abstract | Architecture | Delphi | .NET
