Transactions: .Net and WCF
Transaction Architecture
- Resource Manager (RM)
- RM is system,product or any component which manages data participating in transactions
- RM either commits or Rolls back changes
- for e.g. RDBMS, MSMQ or SQL
- Two types of RMs
- Durable: Resilient to system failures. RMs memorize state of transaction. If system is shut down in between then upon restart Transaction can proceed from its previous state.
- Volatile: Non-resistant to system failures. e.g. This transactional implementation of some core .Net classes.
- Transaction Types
- Long Running
- Long time to complete
- Waiting time for actions and/or messages. i.e. generally waiting for human actions
- Explicit commit & rollbacks (i.e. Compensation)
- No locks are used as it would have severe performance implications
- Atomic
- Take little time to complete
- Implicit commit and rollback
- Locks are acquired to ensure Isolation
- Transaction Protocols
- Decide scope and type of communication between participating applications
- Types of protocols
- Lightweight Protocol
- OleTx Protocol
- WS-Atomic Protocol (WSAT)
- Lightweight Protocol
- Transaction spans across only one AppDomain
- Only one durable RM
- Multiple volatile RMs
- No cross AppDomain calls (no client-server calls)
- Transactions are NOT allowed to propagate to another application or appDomain
- OleTx Protocol
- Allows transaction to cross AppDomain
- Allows transaction to cross machine boundary calls
- Multiple durable RMs
- Windows Remote Procedure Calls (RPC) only
- No cross platform communcation
- Usually not allowed through firewall
- Typically used in Windows intranet scenario
- Allows transaction propagation to other application or appDomain as long as they all run Windows
- WS-Atomic (WSAT)
- One of the WS-* standards
- Same as OleTx plus interoperable communication
- Transaction can propagate to different (non-Windows) platforms
- Transaction Manager
- Transaction Protocol defines transaction boundaries and communication rules
- Transaction Managers manage transactions practically
- Three TMs
- Lightweight Transaction Manager (LTM)
- Uses Lightweight protocol
- Kernel Resource Manager (KRM)
- Uses Lightweight protocol
- Ability to call on distributed File system (TXF) and distributed registry (TXR)
- Distributed Transaction Manager (DTC)
- Uses either the OleTx or WSAT protocol
- Manages transactions across machine and process boundaries
- Promotion
- Transaction Manager selection happens automatically. i.e. System.Transactions has promotions capability.
- Image : "1. Transaction - Promotion"
- Not all RMs support promotion
- RMs must implement IPromotableSinglePhaseNotification interface
- MSMQ and SQL Server 2000 doesn't support promotion
What is 2-Phase Commit Protocol
- Ensures Transaction atomicity across multiple RMs
- Each RM running can fail or commit indecently
- 2-Phase Commit Protocol is used to manage distributed transactions
- Image : "2 Transaction - 2 Phase commit.JPG"
- Image : "3 Transaction - DTC with OleTx Protocol"
WCF Transactions
- Transaction Propagation: Allows clients and services to participate in the same atomic transaction
- Not all WCF bindings support transaction propagation
- When transaction propagates from client to service, DistributedIdentifier for both transaction will be same
- When service operation creates a new transaction (i.e. transaction didn't propagate from client), transaction will first have only LocalIdentifier and DistributedIdentifier will be empty
- Transaction Flow and Transaction Protocols
Image : "4 Transaction - Propagation and Protocol.png"
- Enabling transaction flow
- Step 1: By default bindings disable transaction flow. To enable transaction propagation WCF client should set TransactionFlow attribute of the binding to true.
- Step 2: Configure transaction flow for Service Operation with attribute TransactionFlow. TransacttionFlow has following options.
- NotAllowed: default. Propagation is not allowed. If client tries to propagate transaction it is ignored, no exception is thrown.
- Allowed: If client want to propagate transaction it is allowed, but transaction propagation is not mandatory. If binding doesn't support propagation and client is trying to propagate then an exception would be thrown.
- Mandatory: Propagation is mandatory.Both client and service must use binding which supports propagation and TransactionFlow attibute must be set. Any violation leads to exception.
- OperationBehavior Attribute
- OperationBehavior attribute could be applied on service operation
- It has two parameters
- TransactionScopeRequired: Wraps service operation in TransactionScope
- TransactionAutoComplete: Invokes transactionScope.Complete() method at the end of service operation
- OperationBehavior is oblivious about source of transaction
- It can be propagated from client
- It can be instantiated from server
- Image : "5 Transaction - Transaction Propagation Configuration.JPG"
No comments:
Post a Comment