One or more services together called a transaction group and it ensure that they are executed as if it was just a service action. If one of the service fail all the actions fail and the actions succeed it will result of the service to be committed or permanently stored to the system. The two phase commit transaction ensure that the services participating in a transaction needs to be coordinated in order to assure that either all or none of the services called “commit” their actions within that transaction. The two phase commit protocol includes three steps.
The participants are told to participate in a transaction. All actions are carried out by each participant referring to this transaction must be carried out as a single action. The actions cannot be committed to the main system but it kept internally in the participant or service till the participant is instructed to commit the actions.
All the actions are run successfully by all participants or services, all the services are ordered to move to the prepare phase.
Once the prepare phase is successfully completed the participant must be ensure that all the actions carried out inside the transaction are ready to be committed. If the service fails after it has successfully moved into the prepare phase, it should be able to commit the actions once the service is working correctly. If one of the services cannot move to the prepare phase, all participants are ordered to rollback (abort) the transaction. If all participants successfully move to the prepare phase, then all participants are now ordered to commit their actions. Once committed, the actions are then visible in the system, and permanently executed.
Issues of two phases commit transaction.
The two phase commit protocol is not 100% secure. If a service crashes after entering the prepare phase. Now all services are requested to commit. Imagine that the failed service is the last service in the chain to be ordered to commit. But the commit order fails, because the service has crashed. All other services in this transaction would already have committed their actions, but not this last one.
Normally, the service would have to commit it’s part of the transaction once the service is operational again. However, if the service never comes back up, their action has not been committed.
The below figure illustrate the two phase commit transaction where the last service fails to commit.
The transaction coordination phase helps to say when the transaction begins and when it moves to the prepare phase and commit phase. In this entity the transaction coordinator can be either the following ones.
1) The application
2) An enterprise service bus
3) A separate transaction manager/service
A transaction can be terminated in two ways.
1) Committed -The transaction is committed; all changes made within it are made durable or forced on to stable storage such as disk.
2) Aborted – A transaction is aborted; all changes made during the lifetime of the transaction are undone. Traditional transaction systems are referred to as ACID transactions. The properties of ACID transactions are the following.
- Atomicity: The transaction completes successfully (commits), or if it fails (aborts), all of its effects are undone.
- Consistency: Transactions produce consistent results and preserve application-specific invariants.
- Isolation: Intermediate states produced while a transaction is executing are not visible to other transactions. Furthermore transactions appear to execute serially, even if they are actually executed concurrently. This is typically achieved by locking resources for the duration of the transaction so that they cannot be acquired in a conflicting manner by another transaction.
- Durability: The effects of a committed transaction are never lost (except by a catastrophic failure).
On the service transaction there are three attributes which affect the behavior of the transaction and they do the following ways:-
1) On the ServiceBehaviorAttribute:-
- The TransactionTimeout property defines the time period within which a transaction must complete.
- The TransactionIsolationLevel property defines the isolation level that the service supports. This is required to match the client’s isolation level.
- The ReleaseServiceInstanceOnTransactionComplete property defines whether the service instance is recycled when a transaction completes. By setting it to false, the service maintains the same service instance across the operation requests. This is required to maintain the running total. If set to true, a new instance is generated after each completed action.
- The TransactionAutoCompleteOnSessionClose property determines whether outstanding transactions are completed when the session closes. By setting it to false, the individual operations are needed to either set the OperationBehaviorAttribute TransactionAutoComplete property to true or to explicitly need to a call to the SetTransactionComplete method to complete transactions. This sample demonstrates both approaches
2) On the ServiceContractAttribute:-
- The SessionMode property determines whether the service correlates the appropriate requests into a logical session. Because this services consists of the operations where the OperationBehaviorAttribute TransactionAutoComplete property is set to false (Multiply and Divide), SessionMode.Required must be specified.
Eg: – The multiply operation does not complete its transaction and instead relies upon a later call to Divide to complete using the SetTransactionComplete method; the service must be able to determine that these operations are occurring within the same session.
3) On the OperationBehaviorAttribute:-
- The TransactionScopeRequired property determines whether the operation’s actions should be executed within a transaction scope. This is set to true for all operations in this sample and, because the client flows its transaction to all operations, the actions occur within the scope of that client transaction.
- The TransactionAutoComplete property specifies whether the transaction in which the method executes is automatically completed if no unhandled exceptions occur. This is set to true for the Add and Subtract operations but false for the multiply and Divide operations. The Add and Subtract operations complete their actions automatically, the Divide completes its actions through an explicit call to the SetTransactionComplete method, and the Multiply does not complete its actions but instead relies upon and requires a later call, such as to Divide, to complete the actions.