Distributed Transaction Framework across webservices

Question

I am designing a new system that has one central web service and several site web services which are spread across the country and some overseas. It has some data that must be identical on all sites.

So my plan is to maintain that data in the central web service and then "sync" the data to sites. This includes inserts, edits and deletes.

I see a problem when deleting, if one site has used the record, then I need to undo the delete that has happened on the other servers. This lead me to idea that I need some sort of transaction system that can work across different web servers.

Before I design one from scratch, I would like to know if anyone has come across this sort of problem and if there are any frame works or even design patterns that might aid me?

• Coral Doe: How the data is stored? If you are talking about databases, you can try mirrored configuration for databases.

Answer 1

Sounds like you want to use the two phase commit protocol. A lot of hits come back from a google search, so you'll find plenty to research with.

Here's a quick description from the Wikipedia site.

In a "normal execution" of any single distributed transaction, i.e., when no failure 
occurs, which is typically the most frequent situation, the protocol comprises two phases:
 The commit-request phase (or voting phase), in which a coordinator process attempts 
to prepare all the transaction's participating processes (named participants, cohorts, 
or workers) to take the necessary steps for either committing or aborting the transaction 
and to vote, either "Yes": commit (if the transaction participant's local portion 
execution has ended properly), or "No": abort (if a problem has been detected with the 
local portion), and
 The commit phase, in which, based on voting of the cohorts, the coordinator decides 
whether to commit (only if all have voted "Yes") or abort the transaction (otherwise), 
and notifies the result to all the cohorts. The cohorts then follow with the needed 
actions (commit or abort) with their local transactional resources (also called 
recoverable resources; e.g., database data) and their respective portions in the 
transaction's other output (if applicable).

Answer 2

This is a classic distributed transaction.

First issue a lock to each on he web-services, that lock will freeze all transactions on the targeted record(s). Once all the locks have been secured, issue the delete command.