|< BACK  NEXT >|
For our brokerage firm example, a buy stock transaction consists of the following two operations:
Reduce the number of available shares for the specified stock in the StocksDB database.
Debit the balance in the AccountDB database.
A transaction must be such that it entirely succeeds or entirely fails. This implies that all of the operations involved in the transaction must be updated successfully or nothing should be updated at all. This all-or-nothing proposition of a transaction is called atomicity.
A transaction must be consistent. Any individual operation within a transaction may leave the data in such a state that it violates the system s integrity. In our case, after the completion of the first operation, some shares have been taken out of the market. After the completion of the second operation, either the system should roll back to the original state (restore the shares that were taken out), or, upon success, go to a new state that still maintains the overall integrity of the system.
Now consider the case of concurrent transactions. Suppose that 100 shares of a stock X are available in the StocksDB database, and transaction A, consisting of two operations, is in progress. The first operation has added 50 shares of X into the StocksDB database. This change should be committed only if the second operation succeeds. However, before the second operation completes, another transaction, B, tries to obtain 125 shares of X from the database. Transaction B is able to use the uncommitted changes from transaction A; it actually sees 150 shares of X in the database. This is problematic. What happens if the second operation of transaction A fails and thus the first operation has to be rolled back? Transaction B has been infected with data that never really existed.
To avoid such problems, the system should isolate the uncommitted changes. Transaction B should only be able to see the data in the state before transaction A begins or in the state after transaction A completes, but not in some half-baked condition between the two states.
Finally, a transaction must be durable, that is, when a transaction is committed, the data sources involved must guarantee that the updates will persist, even if the computer crashes (or the power goes off) immediately after the commit. This requires specialized transaction logging that would allow the data source s restart procedure to complete any unfinished operation.
Atomicity, consistency, isolation, and durability; a transaction should support these properties. This is the ACID test for transactions.
Most transactions are not reversible. However, some irreversible transactions can be undone by applying an equal but opposite transaction. An example of such a pair of operations is registering and unregistering a COM server. A transaction that can undo another transaction is referred to as a compensating transaction.
At this point, it is worth considering what implications this has on the underlying components. How on earth can you ensure that the changes in the system can be unwound if the transaction is aborted at some point? Even for our relatively simple example with just two operations, it is not a trivial task. Think about a transaction that involves many such operations.
Fortunately, COM+ provides the infrastructure to ease dealing with transactions.
Let s see it in action.
|< BACK  NEXT >|