4

I'm having trouble updating a single item many times at once. If I try to update an item with new attributes many times like so:

UpdateExpression: 'SET attribute.#uniqueId = :newAttribute'

not all of the updates go through. I tried sending 20 updates with unique ids and this resulted in only 15 new attributes. This also occurs in my local dynamodb instance. I assume that the updates are somehow overwriting each other in a "last update wins" scenario but I'm not sure. How can I solve this?

Lucas D
  • 460
  • 1
  • 4
  • 15
  • Are you adding a new attribute to the item on every single update operation? Otherwise, how are you measuring successful writes? If you are updating the same attribute, they're definitely overwriting each other, last write wins. – Jorge Garcia May 09 '22 at 18:07

2 Answers2

4

DynamoDB is eventually consistent on update, so "race conditions" are possible. If you want more strict logic in writes, take a look at transactions

Items are not locked during a transaction. DynamoDB transactions provide serializable isolation. If an item is modified outside of a transaction while the transaction is in progress, the transaction is canceled and an exception is thrown with details about which item or items caused the exception.

Oleksii Donoha
  • 2,911
  • 10
  • 22
2

Your observation is very interesting, and contradicts observations made in the past in Are DynamoDB "set" values CDRTs? and Concurrent updates in DynamoDB, are there any guarantees? - in those issues people observed that concurrent writes to different set items or to different top-level attributes seem to not get overwritten. Neither case is exactly the same as what you tested (nested attributes), though, so it's not a definitive proof there was something wrong with your test, but it's still surprising.

Presentations made in the past by the DynamoDB developers suggested that in DynamoDB writes happen on a single node (the designated "leader" of the partition), and that this node can serialize the concurrent writes. This serialization is needed to allow conditional updates, counter increments, etc., to work safely with concurrent writes. Presumably, the same serialization could have also allowed multiple sub-attributes to be modified concurrently safely. If it doesn't, it might mean that this serialization is deliberately disabled for certain updates, perhaps all unconditional updates (without a ConditionExpression). This is very surprising, and should have been documented by Amazon...

Nadav Har'El
  • 11,785
  • 1
  • 24
  • 45
  • Yes I agree that the there should be more information on this. I would expect to be able to update separate attributes in parallel without overwrite issues. – Lucas D Jul 12 '20 at 17:56