WCF basicHttpBinding: rollback on failure to respond to a client request

Question

I am showing a WCF service through basicHttpBinding , which performs several database operations.

I want to guarantee that if the client does not receive a response, the database operations will be rolled back (without a transaction flow through WCF). For instance. the client calls the DoX method, which runs on the server, but the client crashes before it finishes. Then database operations should be discarded as soon as the response is not sent to the client.

Is there any way to do this? Will the [OperationBehavior(TransactionScopeRequired=true)] attribute work this way? Is it possible to handle communication errors on the server side?

Update 1: It seems that [OperationBehavior(TransactionScopeRequired=true)] completes the transaction before sending a response to the client and therefore cannot be used to roll back if the client does not receive the response.

Update 2: To make this clear, I don’t need the transaction to interact with the client in any way. The client should not know about the transaction, be able to cancel or commit it, and also should not go through the transaction through the binding. The only place I want the rollback transaction to be done on the server side is if the transport channel cannot deliver the message to the receiving client. In the case of TCP / IP, this information should be easily accessible to the server. (No TCP packet ACK send back to client)

So, a hypothetical server-side execution thread (note the lack of a client side):

 Receive client request Start transaction Execute all logic inside the service operation Send reply back to client if (reply.failedToReceive) { transaction.Rollback() } // due to a failing TCP/IP transmission 

Answer 1

There is no simple answer to this question. You are requesting behavior that is implemented in WS- * but is executed using basic SOAP. I think your only option if you REALLY cannot switch to wsHttpBinding or use duplex, as suggested by @Trevor Pilley, is to try to simulate the behavior of WS-Transaction in your own custom protocol based on the underlying SOAP.

You can get some simplification on the full WS-Transaction specification, because

• You probably only need transaction support through one service — you will not be able to carry out a distributed transaction through several independent services.
• You do not need to support short transactions ( WS-AtomicTransaction ), as well as long transactions ( WS-BusinessActivity ) probaby atomic transactions will do
• You do not need to support any extensibility model ( WS-Coordination )
• You will not need to implement a discovery / metadata model that describes the protocol (for example, as WSDL), because you will code the protocol behavior directly in the client and service.

However, you will probably need WS-Coordination and WS-AtomicTransaction elements. This is not an easy task by any means, and it will be easy to miss something subtle, which can result in rollbacks not occurring or (just as badly) to disrupt the performance of your service, having long locks across your database due to broken customers.

As I said, this is complex behavior, and if you cannot use ready-made standardized protocols, there is no simple answer.