WCF basicHttpBinding: Rollback when reply to client fails

Question

I am exposing a WCF service through a basicHttpBinding that executes several operations on a database.

I want to guarantee that if the client does not receive the reply the database operations are rolled back (without any transaction flow through WCF). E.g. the client calls the "DoX" method which executes on the server but before it is finished the client crashes. The database operations should then be rolled back as soon as the reply can not be send to the client.

Is there any way to do that? Will the [OperationBehavior(TransactionScopeRequired=true)] attribute work in such a manner? Is there a possibility to handle communication errors on the server side?

Update 1: It seems [OperationBehavior(TransactionScopeRequired=true)] commits the transaction before the reply is send to the client and thus can not be used to perform a rollback if the client does not receive the reply.

Update 2: To state it clearly again, I do not have the need for the transaction to interact in any way with the client side. The client should neither know of the transaction, have the ability to cancel or commit it, nor should any transaction flow through the binding. The only place I want the transaction to rollback is on the server side if the transport channel can not deliver the message to the receiving client. With the case of TCP/IP this information should be readily available to the server. (No ACK of the TCP packet send back to the client)

So a hypothetical execution flow on the server side (notice the lack of client side) should be:

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 easy answer to this question. You are asking for a behaviour that is implemented in WS-* but done using basic SOAP. I think your only option if you REALLY can't switch to wsHttpBinding or use duplex as suggested by @Trevor Pilley is to try to mimic the behaviour of WS-Transaction in your own custom protocol based on basic SOAP.

You should be able to get some simplification over the full WS-Transaction specification because

• You will probably only need to support transactions over a single service - you will not be doing a distributed transaction over several independent services
• You will not need to support both short a transactions (WS-AtomicTransaction) as well as long running transactions (WS-BusinessActivity) probaby atomic transactions would do
• You would not need to support any kind of extensibility model (WS-Coordination)
• You would not need to implement a discovery/metadata model that describes the protocol (e.g. like WSDL) because you would be coding the protocol behaviour directly into the client and service.

However, you would probably need elements of both WS-Coordination and WS-AtomicTransaction. This is not a simple task by any means and it will be easy to miss something subtle that could cause either rollbacks to not happen or (just as bad) to destroy the performance of your service by having long duration locks all over your database due to crashed clients.

Like I say, this is a complex behaviour and if you cannot use ready-made, standardised protocols, there is no simple answer.