- [Morgan] When working with DynamoDB or any data source, you most likely won't just have one application or process reading and writing from your database. You instead will likely have multiple readers and writers concurrently accessing your data. One consideration when working with multiple readers and writers to a singular DynamoDB table is the issue of concurrent updates. Let's say I have two applications, Application A and Application B, that are both reading from and writing to the same DynamoDB table at the same time. Application A is trying to update an item. How do I make sure that the item Application A wants to update hasn't been overwritten by Application B before Application A can finish its update? DynamoDB does not support locking of objects the way a relational database normally does. That means, locking is something you would design into your table and into your application code. One way to handle this is by using a strategy called optimistic locking. Optimistic locking is a strategy used to ensure that the item an application is working on is the same item that is in DynamoDB and hasn't been overwritten since the last time it was read. The optimistic locking strategy also relies on a feature of DynamoDB called a conditional write. Conditional writes apply to the PutItem, UpdateItem, and DeleteItem API calls, and this can be useful in many different situations. For example, you could use a conditional write to only allow a PutItem to succeed if there isn't already a value for that key in your table. Another example is you can use a conditional write to only allow an UpdateItem API call to succeed if one of the attributes has a specific value. And that's what we're going to do for optimistic locking. To use optimistic locking, you will need to include an attribute for a version number on the items you are trying to lock, and also make use of the DynamoDB conditional write. When doing an update, the application would retrieve the item from the table and keep track of the current value for the version number. Then, when you go to call the UpdateItem API, you would include a conditional in that call that checks to ensure that the version number in the DynamoDB table is the same version number that you have kept record of when you first retrieved the item. If the value of the version attribute has changed, it means that another application has modified the item before you did, and the update should fail, because the version you have is stale. To finish the update successfully, you simply would retrieve the latest version of the item, make your changes, and try the update again. When an update succeeds, the version number would be incremented to show any other concurrent users of the data that a change has been made, and they might need to refresh before writing again. Optimistic locking is one way to enforce that concurrent updates of an item do not overwrite each other. Keep in mind, though, this is something that happens at the application level, and you must remember to include the version number as an attribute for the items in question. For more information on optimistic locking, check out the course notes, and that's all for now.