Is transaction between a web service and a database possible?

I want to call a web service to insert a record in it's database and then I want to Insert a record in a remote database in the other city if web service do the operation successfully.

here is a simplified sample code:

IdentificationSystem.Service Identify = new IdentificationSystem.Service();
        s开发者_如何学JAVAtring result= Identify.InsertWorkshopInfo(BosWorkshop.WpSvUserName, BosWorkshop.WpSvPassword,BosWorkshop.WkIcode,BosWorkshop.WpName)

if (result==0)//If success
 {
   Connect to a remote database and then insert a record 
}

according to my sample code what will happen if data inserted via web service and web service return success but I can't insert the record in remote database in the other city. something like connection loose.

What should I do? Can I use System.transaction name space here? I'm writing the web service code my self.

If both servers are running the Distributed Transaction Coordinator (MSDTC), then yes, a distributed transaction is possible.

A TransactionScope transaction will automatically escalate using the DTC.

BUT, it you should consider the implications: a long running transaction across servers is probably not desirable. Also, there are security and firewall considerations.

There are WS standards for dealing with distributed transactions see this document , but using those requires that the authors of the Web Service should choose to offer interfaces that conform to those more advanced specifications. This adds considerable complexity to the implementations and administration of the web services so few service providers choose to do this.

If the absence of some kind of distributed transaction coordination the responsibility for any such consistency lies with the client, ie. you. Effectively you need to keep a reliable record of what you want are trying to do (I need to intert this here and that there) and then have some mecanism to cope with failures, such as retrying at some point in the future, or undoing the first insert if the second one becomes impossible.

Various "process choreography" products attempt to simplify the coding of such rules, but this is a really difficult problem to solve completely. To give a couple of examples:

• Every service you use needs to have some kind of undo capability. Some services (eg. send a n email) do not naturally have undo. Others have a financial cost for undoing (eg. cancel a reservation may cost a deposit). Worse, some service auathors don't provide an undo capability.
• You don't always know whether an action was actually completed. You send a request, you then crash and hence don't see the response. Now, do you retry and risk making (say) a double debit? Ideally the service author provides idempotent services (services that can safely deal with repeated requests for the same action) and/or some query capability that lets you discover the fate of a request.

My general thought you are dependent on your services providers to provide you with services that allow you to "compose" the multi-update functionality you desire. If you are very unlucky what you want to do may be impossible. You then fall back to manual correction for some failure scenarios. Real-world businesses actually do a lot of that. People get on the phone to determine what happened, to adjust orders, even to ask for orders to be cancelled. If the likelihood of failure is small, then this may be a more cost-effective approach that developing a bullet proof system.