Question

In my PHP application ( constructed using symfony framework and Propel ORM), when I add a record to the MYSQL database, I need to update an external MYSQL database using web service API provided by the external vendor.

The question is what is the best practice to maintain the database integrity. Take for example, if the first update is successful, and the second update is not, due to the fact that web service isn’t available, I must be able to either

1. Rollback the transaction for the first update, or
2. cache the call to the web services and keep calling to the web services until the services become available
3. Some other techniques that can maintain the multiple database integrity.

Specifically, I am looking for syntax like

void RootMethod() {      using(TransactionScope scope = new TransactionScope())      {         try          {            SomeMethod();           scope.Complete();           CallWebService();          }          catch          {              scope.abort();           }      } } 

But not sure whether

1. This is a good technique
2. Or is this feasible in symfony as in C#

What do you think?

Edit: Some asked me why there is a need for two part update. It’s because I am creating a front end application connecting to an existing back end application. And I don’t want to change the back end application. So inevitably there will be some overlap. Therefore there is a need to synch the data

Another Edit: The two parts transaction must be done together, doing a cron job to synchronize the table is not desirable

Answer 1

This is going to be tricky. You need 2 phase commit for a reliable solution, but that would be a ton of work to implement for your specific needs.

Maybe a great solution is not actually called for. Are you under difficult performance constraints? Generally transactions should be short in time… but maybe you should keep the transaction open around the webservice call? This would reduce the overall throughput of the database (at the least)… but that might be perfectly acceptable.

The approach you showed will have problems handling hard system failures (power failures, hardware faults, etc). To work around that you’ll need to add tracking to your main database and a background process/startup process to handle failures. Pretty fiddly to do, but certainly possible.

Some failures might end up not being fixable (first part succeeded, second part failed, first part can’t be undone because another transaction has updated the same data). It all depends on your precise business rules. An accounting system would be the easiest because undo’ng a transaction is actually done as offseting records and not updates.

Good luck.