Azure Table Storage - Managing Concurrency

Question

I read this online article about concurrency in Microsoft Azure Storage, specifically Table Storage. https://azure.microsoft.com/en-us/blog/managing-concurrency-in-microsoft-azure-storage-2/

It explains that Table Storage will default to optimistic concurrency strategy. The use of E-Tags is key to implementing the strategy. For example, the Replace operation requires an If-Match of E-Tags, and will always return E-Tags in the service response. So if I want to use Replace operation, I have to make sure the entity I'm sending has an E-Tag value. This has implications on design. For instance, I have to be careful when abstracting my application domain entities from my data record entities, because mapping between layers will lose the E-Tag context, unless I introduce the concept of E-Tag perhaps as correlation id which is more application wide generic to my domain entities. So that is not a problem. The problem is my confusion in the InsertOrReplace operation. It does not require If-Match. How is this possible when the operation does a Replace? Also, how does this impact concurrency management? Does this mean that specific to InsertOrReplace operation, the TableService will default to last writer win strategy instead?

Answer 1

Yes, Azure Storage Table Service will accept the request per last writer win strategy for InsertOrReplace operation.

The Insert Or Replace Entity operation does not use the If-Match header and it must be called using the 2011-08-18 version or newer. These attributes distinguish this operation from the Update Entity operation. If the Insert Or Replace Entity operation is used to replace an entity, any properties from the previous entity will be removed if the new entity does not define them. Properties with a null value will also be removed.

If you want last writer win strategy for Replace operation as well, set ETag to "*".

To force an unconditional update operation, set the value of the If-Match header to the wildcard character (*) on the request. Passing this value to the operation will override the default optimistic concurrency and ignore any mismatch in ETag values.