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.
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.
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:-
2) On the ServiceContractAttribute:-
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:-