CODEWITHSUNDEEP
azureazure-functionsazure-table-storage
Niels Brinch
Niels Brinch

Reputation: 3612

New item inserted in Azure Table Storage is not immediately available

I have

If I insert an item and then immediately get that same item, then the item has not appeared yet!

If I delay by one second after saving, then I find the item.

If I delay by 10ms after saving, then I don't find the item.

I see the same symptom when updating an item. I set a date field on the item. If I get immediately after deleting, then some times the date field is not set yet.

Is this known behavior in Azure Table Storage? I know about ETags as described here but I cannot see how it applies to this issue.

I cannot easily provide a code sample because this is distributed among multiple functions and I think if I did put it in a simpler example, then there would be some mechanism that would see I am calling from the same ip or with the same client and manage to return the recently saved item.

Upvotes: 2

Views: 494

Answers (2)

Gaurav Mantri
Gaurav Mantri

Reputation: 136186

As mentioned in the comments, Azure Table Storage is Strongly Consistent. Data is available to you as soon as it is written to Storage.

This is in contrast with Cosmos DB Table Storage where there are many consistency levels and data may not be immediately available for you to read after it is written depending on the consistent level set.

Upvotes: 2

Niels Brinch
Niels Brinch

Reputation: 3612

The issue was related to my code and queues running in the background.

I had shut down the Function that has queue triggers but to my surprise I found that the Function in my staging slot was picking items off the queue. That is why it made a difference whether I delay for a second or two.

And to the second part, why a date field is seemingly not set as fast as I get it. Well, it turns out I had filtered by columns, like this:

var operation = TableOperation.Retrieve<Entity>(partitionKey, id, new List<string> { "Content", "IsDeleted" });

And to make matters worse, the class "Entity" that I deserialize to, of course had default primitive values (such as "false") so it didn't look like they were not being set.

So the answer does not have much to do with the question, so in summary, for anyone finding this question because they are wondering the same thing:

The answer is YES - Table Storage is in fact strongly consistent and it doesn't matter whether you're 'very fast' or connect from another location.

Upvotes: 1

Related Questions