These series of posts dealt with various aspects of dealing with failures while saving information on Windows Azure Storage: Windows Azure Guidance - Additional notes on failure recovery on Windows Azure Windows Azure Guidance – Failure recovery and data consistency – Part II Windows Azure Guidance ...

In the previous post , my question was about a small change in the code that would yield a big improvement. The answer is:   What changed? No try / catch We reversed the order of writes : first we write the details, then we write the “header” or “master” record for the expense. If the last SaveChanges...

I had some great answers on my previous post question, like Simone ’s. Some where closer than others, but in general you got it right, Thanks! The recovery strategy depicted there assumes that all failures are external . That is, writing to a table fails, for example, and you have a chance to run the...

Things will eventually fail in your application and you need to be prepared. So most components should be designed for something going wrong and recover gracefully (or as gracefully as possible) and leaving the system in a consistent state (eventually in some cases). In this post I wrote about dealing...

This new release focuses primarily on replacing the data tier with Azure Table Storage. To make things more interesting, we changed the data model in a-Expense so it now requires two different related entities: the expense report “header” (or master) and the details (or line items) associated with it...

For years now, we have been using transactions in our systems. Years ago, there's been a democratization of the more complex concepts underlying transaction management and we've been quite happy. On the Microsoft side there's been technologies like: MTS, COM+, Enterprise Services, DTC and of course SQL...