A transaction is a collection or group of one or more units of
operation executed as a whole. It provides way to logically group single
piece of work and execute them as a single unit. In addition, WCF
allows client applications to create transactions and to propagate
transactions across service boundaries.
Recovery Challenge
Let us discuss more on challenge we will phased and how to recover from it.
- Consider a system maintained in consistent state, when
application fail to perform particular operation, you should recover
from it and place the system in the consistent state.
- While doing singe operation, there will be multiple atomic sub
operation will happen. These operations might success or fail. We are
not considering about sub operation which are failed. We mainly consider
about the success operation. Because we have to recover all these state
to its previous consistence state.
- Productivity penalty has to be payee for all effort required for handcrafting the recovery logic
- Performance will be decreased because you need to execute huge amount of code.
Solution
Best way to maintain system consistence and handling error-recovery challenge is to use transactions.
Below figure gives idea about transaction.
- Committed transaction: Transaction that execute successfully and transfer the system from consistence state A to B.
- Aborted transaction: Transaction encounters an error and rollback to Consistence State A from intermediate state.
- In-doubt transaction: Transactions fail to either in commit or abort.
Transaction Resources
Transactional programming requires working with a resource that is
capable of participating in a transaction, and being able to commit or
roll back the changes made during the transaction. Such resources have
been around in one form or another for decades. Traditionally, you had
to inform a resource that you would like to perform transactional work
against it. This act is called enlisting. Some resources support
auto-enlisting.
Transaction Properties
Transaction can be said as pure and successful only if meets four characteristics.
- Atomic - When transaction completes, all the individual changes
made to the resource while process must be made as to they were all one
atomic, indivisible operation.
- Consistent - transaction must leave the system in consistent state.
- Isolated - Resources participating in the transaction should be locked and it should not be access by other third party.
- Durable - Durable transactions must survive failures.
No comments:
Post a Comment