Atomic Counters might require ConsistentRead to work properly in concurrency scenarios

[davidrissato]

I have faced an issue of undercounting when I was trying to use Atomic Counters and I found the information in this guide slightly incomplete.

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/WorkingWithItems.html#WorkingWithItems.AtomicCounters says: "...If an UpdateItem operation should fail, the application could simply retry the operation. This would risk updating the counter twice, but you could probably tolerate a slight overcounting or undercounting of website visitors. An atomic counter would not be appropriate where overcounting or undercounting cannot be tolerated (For example, in a banking application). In this case, it is safer to use a conditional update instead of an atomic counter."

The way it is written, it might give the impression that this issue would only happen in case you had a problem in your application logic. I faced this behavior when I was keeping atomic counters in high concurrency scenarios, even though my app was behaving accordingly.

And I also discovered that if you add the ConsistentRead parameter to that update command, it will avoid this problem, like this:

aws dynamodb update-item \
    --table-name ProductCatalog \
    --key '{"Id": { "N": "601" }}' \
    --update-expression "SET counter = counter + :incr" \
    --expression-attribute-values '{":incr":{"N":"1"}}' \
    --consistent-read \
    --return-values UPDATED_NEW

Is that the correct approach? In case this is true, I believe it would be helpful to update that atomic counters example with the one above.

[santisra]

Thanks for your feedback. I'll look into this.

[Damiox]

Hello @santisra could you please clarify what @davidrissato is asking for? I think it's important to understand from the documentation if the AtomicCounter issue can be worked around or not without having to pre-read the elements and do a conditional update. Thanks

[joshbean]

Closing this issue or pull request in advance of archiving this repo. For more information about the decision to archive this repo (and others in the 'awsdocs' org), see the announcement on the AWS News Blog.