Azure Tips and Tricks Part 88 - What’s the purpose of ETag in Azure Storage Table?

Azure Developer Guide Book 2nd Edition available now! This free eBook is available now at aka.ms/azuredevebook.

Intro

Most folks aren’t aware of how powerful the Azure platform really is. As I’ve been presenting topics on Azure, I’ve had many people say, “How did you do that?” So I’ll be documenting my tips and tricks for Azure in these posts.

The Complete List of Azure Tips and Tricks

Available Now!

What’s the purpose of ETag in Azure Storage Table?

In case you are new to the Azure Storage Tables, we’ve reviewed the following items so far:

• Creating your first Azure Storage Table
• Adding an item to a Azure Storage Table
• Reading an item from a Azure Storage Table
• Updating an item from a Azure Storage Table
• Deleting an item from a Azure Storage Table
• Ensure a clean RowKey in Azure Storage Table
• What’s the purpose of ETag in Azure Storage Table?

What is it?

There is a lot of confusion around ETag and I thought I’d stop for a moment to help clear this up.

An ETag property is used for optimistic concurrency during updates. It is not a timestamp as there is another property called TimeStamp that stores the last time a record was updated. For example, if you load an entity and want to update it, the ETag must match what is currently stored. This is important b/c if you have multiple users editing the same item, you don’t want them overwriting each other’s changes.

A Practical Example

Bob and David load an edit page on a website at the same time. Bob changes a value for Description and saves the item. After David has had the form open for a while and makes a change to a unrelated field such as the URL and unknowingly the outdated Description is being saved with their update. David does not know they are discarding a change by Bob unless you alert him. So what you should do is show an error that Bob has changed it already and ask if they sure they want to overwrite Bob’s changes or if they want to see those changes first.

This is accomplished by both Bob and David storing the ETag from when the record was loaded. When each user attempts a save you can pass that ETag to the server with the updated data and see if they match. Every change to a record updates the ETag stored for that record. So when David tries to save the ETag that is conflicting, then it won’t match and you can handle what should be done.

If you don’t care that David’s changes may overwrite Bob’s changes, then you can pass “*” with the save and Azure won’t give an error when the ETag does not match.

** Original credit goes to Michael Lang for this example, I’ve made minor tweaks to help folks understand it better. **

Wrap-up

I hope that bring some clarity to the issue as it has been confusing to me over the years.

Want more Azure Tips and Tricks?

If you’d like to learn more Azure Tips and Tricks, then follow me on twitter or stay tuned to this blog! I’d also love to hear your tips and tricks for working in Azure, just leave a comment below.