CODEWITHSUNDEEP
amazon-dynamodboptimistic-locking
ishan3243
ishan3243

Reputation: 1928

DynamoDB save() API: Optimistic Locking and SaveBehavior

The save API of dynamodb provides multiple save-behaviors including UPDATE, UPDATE_SKIP_NULL_ATTRIBUTES, CLOBBER, and APPEND_SET.

According to this doc Optimistic Locking via version attribute is enabled if save-behavior is UPDATE and disabled if it is CLOBBER. Two questions regarding this:

  1. Why would someone want to disable Optimistic Locking? Optimistic Locking is giving you safe writes to your records!
  2. What about the other save-behaviors? Does it even make sense to use UPDATE_SKIP_NULL_ATTRIBUTES and APPEND_SET with a version attribute? Reason being, you could simply skip the version attribute while calling save() which is a bit hard to digest.

Upvotes: 1

Views: 3763

Answers (1)

Mike Dinescu
Mike Dinescu

Reputation: 55720

I'll try to answer each of your questions:

  1. Why would someone want to disable Optimistic Locking? Optimistic Locking is giving you safe writes to your records!

True - optimistic concurrency gives you safe access to your records, but it's not free(*), and you have to decide what to do if an update fails. On the other hand if the table is structured such that there is no possibility for concurrent updates (for instance, you have a table where items are only ever written once, each with a unique key, then why take the extra cost of the optimistic lock?)

(*) an UPDATE with optimistic concurrency requires you to first read the record, then try to update it supplying the version you've just read which means that it is more expensive (you have to pay for a read and a write, potentially multiple reads and write if there is contention) and takes longer (again you have to read and only after that you can attempt to update). If you have another way to ensure that only one writer may be able to update the record, there is no need to use optimistic concurrency.

  1. What about the other save-behaviors? Does it even make sense to use UPDATE_SKIP_NULL_ATTRIBUTES and APPEND_SET with a version attribute? Reason being, you could simply skip the version attribute while calling save() which is a bit hard to digest.

The UPDATE_SKIP_NULL_ATTRIBUTES is actually pretty powerful. It enables you to only apply partial updates to an item. Let's say that you have a complex item that stores state for multiple components of a system, all in the same record. When one of the components changes state, you can simply apply an update with UPDATE_SKIP_NULL_ATTRIBUTES without having to worry about accidentally modifying the other attributes.

The APPEND_SET mode is similar to UPDATE_SKIP_NULL_ATTRIBUTES but it changes the behavior of updates to attributes stored as sets from the default of overwriting the whole set to appending to the set. Personally I haven't found it super useful but I can image it could be useful.

The final question is, does it even make sense to use something like UPDATE_SKIP_NULL_ATTRIBUTES with optimistic concurrency

I think it kind of depends on how you architect your system. It is conceivable to have a table, with GSIs that projects parts of each item, with a key and the version attributes. Then, you could read from the GSI only what you need, and then if you would like to apply a partial update you can do so optimistically.

Upvotes: 1

Related Questions