Internal details of how 2 phase or 3 phase commit works over WCF

Question

[ServiceContract]
public interface Iservice2
{
    [OperationContract]
    [TransactionFlow(TransactionFlowOption.Allowed)]
    void UpdateService2();
}

[ServiceContract]
public interface Iservice1
{
    [OperationContract]
    [TransactionFlow(TransactionFlowOption.Allowed)]
    void upload();

}

Client Code

using (var scope = new TransactionScope())
{
    IserviceClient client = new Iservice1Client();
    client.upload();

    Iservice2 test = new Iservice2Client();

    test.UpdateService2();

    MessageBox.Show("All is well!!!");

    scope.Complete();
}

I want to understand 2 phase or 3 phase commit in detail over WCF.

I understand theoretically the architecture of the 2 phase commit.

Understanding

The service1 and service2 are hosted in different URLS
The above does a distributed transaction

Questions

When WCF is configured as PerCall, how does the distributed transaction happen internally in WCF - does it momentarily save the state to session so that it can commit when the actual commit is called?
So is the session of the states kept alive from client till the transaction is completed? - Does it keep the reference of the DB transaction ?
When you get concurrent request does WCF guarantee that 2 request will have 2 different transactions and will not club them together - if so how does it know that it is 2 different request?

The question may be elementary, however i am looking to understand the above concepts to design a solution for my project.

I found the answer as to how Distributed transaction works http://stackoverflow.com/a/494593/799329 — user799329, Apr 07 '15 at 11:20

tom redfern · Answer 1 · 2015-04-01T16:13:54.207

Your question contains about 6 questions. I will try to address them one at a time.

I want to understand 2 phase or 3 phase commit in detail over WCF.

WCF uses either WS-AtomicTransaction or OleTransaction via MSDTC to orchestrate transactions, and both these standards only support 2-phase commit.

When WCF is configured as PerCall, how does the distributed transaction happen internally in WCF

You are asking a question that can probably only be answered by the developers who wrote WCF.

does it momentarily save the state to session so that it can commit when the actual commit is called

A process similar to what you describe must logically happen, but the internals of how this works is unimportant. That it does actually work is important. This is managed by the resource manager on the machine which this service lives on. From msdn:

For distributed transactions, each computer has a local transaction manager. When a transaction does work at multiple computers, the transaction managers interact with other transaction managers via either a superior or subordinate relationship. These relationships are relevant only for a particular transaction.

So is the session of the states kept alive from client till the transaction is completed? - Does it keep the reference of the DB transaction ?

See answer to above question.

When you get concurrent request does WCF guarantee that 2 request will have 2 different transactions and will not club them together

It better do.

if so how does it know that it is 2 different request?

When a request comes in a thread is dispatched to service the request. If WCF couldn't distinguish two different incoming requests then I don't think Microsoft would have released it as an enterprise-grade web service platform.

i am looking to understand the above concepts to design a solution for my project

Perhaps you would be better off trying to understand how distributed transactions work on windows:

From Pro WCF 4: Practical Microsoft SOA Implementation By Nishith Pathak:

The two-phase commit protocol lets all the nodes involved in a distributed transaction participate in an atomic manner...(and) has three stages: active, phase 1, and phase 2. In the active stage the transaction is created. The superior resource manager (the resource manager of the creator) enlists the other resource managers, who become active in the transaction. In Phase 1, the creator issues the commit command for the transaction, and the enlisted resource managers respond about whether they are prepared to commit. If the managers are prepared to commit, the transaction will move to phase 2, otherwise it will abort.

In phase 2, the superior resource manager will write a durable entry into an internal log, and then issue the commit to the enlisted resource managers. Once this is done, the superior resource manager will begin sending the commit to the enlisted resource managers and, irrespective of any errors...will continue until all enlisted resource managers have been sent a commit message. Then the superior resource manager will wait for the confirmation of the commit from the enlisted resource managers, for an error message, or until a timeout occurs. Should all enlisted resource managers respond positively about the commit, the superior resource manager will erase the log entry, and the transaction will end.

Thanks for your answer tom. However, i know that distributed transaction works and have tested them. However, my purpose for this question was to get a deeper understanding how it works like how the 2 requests are differentiated logically and etc. — user799329, Apr 01 '15 at 23:39
@user799329 - You say you want to design a solution for your project. I am assuming you have a requirement for web services and transactions. If this is the case then are you seeking deeper understanding because you have not decided to use WCF yet? I'm interested to know how you are planning on using this information once you have found it out. Thanks — tom redfern, Apr 02 '15 at 07:44

Internal details of how 2 phase or 3 phase commit works over WCF

1 Answers1