AWS amazondynamodb documentation change
Summary
Complete restructuring of the document: Changed focus from version control implementation to broader concurrency control strategies. Added sections comparing optimistic/pessimistic locking, decision guidelines, and global tables limitations. Removed specific implementation examples and diagrams.
Security assessment
The changes focus on general concurrency control best practices without addressing specific vulnerabilities. No evidence of security patches or vulnerability disclosures. The global tables note highlights data consistency limitations, but this is a reliability concern rather than a security vulnerability.
Diff
diff --git a/amazondynamodb/latest/developerguide/BestPractices_ImplementingVersionControl.md b/amazondynamodb/latest/developerguide/BestPractices_ImplementingVersionControl.md index 5af149d2e..091ee1056 100644 --- a//amazondynamodb/latest/developerguide/BestPractices_ImplementingVersionControl.md +++ b//amazondynamodb/latest/developerguide/BestPractices_ImplementingVersionControl.md @@ -5 +5 @@ -When to use this patternPattern designUsing the pattern +Choosing a concurrency control strategy @@ -7 +7 @@ When to use this patternPattern designUsing the pattern -# Best practices for implementing version control in DynamoDB +# Best practices for handling concurrent updates in DynamoDB @@ -9 +9 @@ When to use this patternPattern designUsing the pattern -In distributed systems like DynamoDB, item version control using optimistic locking prevents conflicting updates. By tracking item versions and using conditional writes, applications can manage concurrent modifications, ensuring data integrity across high-concurrency environments. +In distributed systems, multiple processes or users may attempt to modify the same data at the same time. Without concurrency control, these concurrent writes can lead to lost updates, inconsistent data, or race conditions. DynamoDB provides several mechanisms to help you manage concurrent access and maintain data integrity. @@ -11 +11 @@ In distributed systems like DynamoDB, item version control using optimistic lock -Optimistic locking is a strategy used to ensure that data modifications are applied correctly without conflicts. Instead of locking data when it's read (as in pessimistic locking), optimistic locking checks if data has changed before writing it back. In DynamoDB, this is achieved through a form of version control, where each item includes an identifier that increments with every update. When updating an item, the operation will only succeed if that identifier matches the one expected by your application. +###### Note @@ -13 +13 @@ Optimistic locking is a strategy used to ensure that data modifications are appl -## When to use this pattern +Individual write operations such as `UpdateItem` are atomic and always operate on the most recent version of the item, regardless of concurrency. Locking strategies are needed when your application must read an item and then write it back based on the read value (a read-modify-write cycle), because another process could modify the item between the read and the write. @@ -15 +15 @@ Optimistic locking is a strategy used to ensure that data modifications are appl -###### This pattern is useful in the following scenarios: +There are two primary strategies for handling concurrent updates: @@ -17 +17 @@ Optimistic locking is a strategy used to ensure that data modifications are appl - * Multiple users or processes may attempt to update the same item concurrently. + * **Optimistic locking** – Assumes conflicts are rare. It allows concurrent access and detects conflicts at write time using conditional writes. If a conflict is detected, the write fails and the application can retry. @@ -19 +19 @@ Optimistic locking is a strategy used to ensure that data modifications are appl - * Ensuring data integrity and consistency is paramount. + * **Pessimistic locking** – Assumes conflicts are likely. It prevents concurrent access by acquiring exclusive access to a resource before modifying it. Other processes must wait until the lock is released. @@ -21 +20,0 @@ Optimistic locking is a strategy used to ensure that data modifications are appl - * There is a need to avoid the overhead and complexity of managing distributed locks. @@ -24,0 +24 @@ Optimistic locking is a strategy used to ensure that data modifications are appl +The following table summarizes the approaches available in DynamoDB: @@ -26 +26,5 @@ Optimistic locking is a strategy used to ensure that data modifications are appl -###### Examples include: +Approach | Mechanism | Best for +---|---|--- +Optimistic locking | Version attribute + conditional writes | Low contention, inexpensive retries +Pessimistic locking (transactions) | `TransactWriteItems` | Multi-item atomicity, moderate contention +Pessimistic locking (lock client) | Dedicated lock table with lease and heartbeat | Long-running workflows, distributed coordination @@ -28 +32 @@ Optimistic locking is a strategy used to ensure that data modifications are appl - * E-commerce applications where inventory levels are frequently updated. +## Choosing a concurrency control strategy @@ -30 +34 @@ Optimistic locking is a strategy used to ensure that data modifications are appl - * Collaborative platforms where multiple users edit the same data. +Use the following guidelines to choose the right approach for your workload: @@ -32 +36 @@ Optimistic locking is a strategy used to ensure that data modifications are appl - * Financial systems where transaction records must remain consistent. +**Use optimistic locking** when: @@ -34,0 +39 @@ Optimistic locking is a strategy used to ensure that data modifications are appl + * Conflicts are infrequent. @@ -35,0 +41 @@ Optimistic locking is a strategy used to ensure that data modifications are appl + * Retrying a failed write is inexpensive. @@ -37 +43 @@ Optimistic locking is a strategy used to ensure that data modifications are appl -### Tradeoffs + * You are updating a single item at a time. @@ -39 +44,0 @@ Optimistic locking is a strategy used to ensure that data modifications are appl -While optimistic locking and conditional checks provide robust data integrity, they come with the following tradeoffs: @@ -41 +45,0 @@ While optimistic locking and conditional checks provide robust data integrity, t -**Concurrency conflicts** @@ -44 +48 @@ While optimistic locking and conditional checks provide robust data integrity, t -In high-concurrency environments, the likelihood of conflicts increases, potentially causing higher retries and write costs. +**Use transactions** when: @@ -46 +49,0 @@ In high-concurrency environments, the likelihood of conflicts increases, potenti -**Implementation complexity** @@ -47,0 +51 @@ In high-concurrency environments, the likelihood of conflicts increases, potenti + * You need to update multiple items atomically. @@ -49 +53 @@ In high-concurrency environments, the likelihood of conflicts increases, potenti -Adding version control to items and handling conditional checks can add complexity to the application logic. + * You require all-or-nothing semantics across items or tables. @@ -51 +55 @@ Adding version control to items and handling conditional checks can add complexi -**Additional storage overhead** + * You need to combine condition checks with writes in a single operation. @@ -54 +57,0 @@ Adding version control to items and handling conditional checks can add complexi -Storing version numbers for each item slightly increases the storage requirements. @@ -56 +58,0 @@ Storing version numbers for each item slightly increases the storage requirement -## Pattern design @@ -58 +60 @@ Storing version numbers for each item slightly increases the storage requirement -To implement this pattern, the DynamoDB schema should include a version attribute for each item. Here is a simple schema design: +**Use the lock client** when: @@ -60 +61,0 @@ To implement this pattern, the DynamoDB schema should include a version attribut - * Partition key – A unique identifier for each item (ex. `ItemId`). @@ -62 +63 @@ To implement this pattern, the DynamoDB schema should include a version attribut - * Attributes: + * You need to coordinate access to external resources across distributed processes. @@ -64 +65 @@ To implement this pattern, the DynamoDB schema should include a version attribut - * `ItemId` – The unique identifier for the item. + * The critical section is long-running and retrying on conflict is expensive. @@ -66 +67 @@ To implement this pattern, the DynamoDB schema should include a version attribut - * `Version` – An integer that represents the version number of the item. + * You need automatic lock expiry to handle process failures. @@ -68 +68,0 @@ To implement this pattern, the DynamoDB schema should include a version attribut - * `QuantityLeft` – The remaining inventory of the item. @@ -71,0 +72 @@ To implement this pattern, the DynamoDB schema should include a version attribut +###### Note @@ -73,85 +74 @@ To implement this pattern, the DynamoDB schema should include a version attribut -When an item is first created, the `Version` attribute is set to 1. With each update, the version number increments by 1. - - - -## Using the pattern - -To implement this pattern, follow these steps in your application flow: - - 1. Read the current version of the item. - -Retrieve the current item from DynamoDB and read its version number. - - def get_document(item_id): - response = table.get_item(Key={'ItemID': item_id}) - return response['Item'] - - document = get_document('Bananas') - current_version = document['Version'] - - 2. Increment the version number in your application logic. This will be the expected version for the update. - - new_version = current_version + 1 - - 3. Attempt to update the item using a conditional expression to ensure the version number matches. - - def update_document(item_id, qty_bought, current_version): - try: - response = table.update_item( - Key={'ItemID': item_id}, - UpdateExpression="set #qty = :qty, Version = :v", - ConditionExpression="Version = :expected_v", - ExpressionAttributeNames={ - '#qty': 'QuantityLeft' - }, - ExpressionAttributeValues={ - ':qty': qty_bought, - ':v': current_version + 1, - ':expected_v': current_version - }, - ReturnValues="UPDATED_NEW" - ) - return response - except ClientError as e: - if e.response['Error']['Code'] == 'ConditionalCheckFailedException': - print("Update failed due to version conflict.") - else: - print("Unexpected error: %s" % e) - return None - - update_document('Bananas', 2, new_version) - -If the update is successful, the QuantityLeft for the item will be reduced by 2. - - - - 4. Handle conflicts if they occur. - -If a conflict occurs (e.g., another process has updated the item since you last read it), handle the conflict appropriately, such as by retrying the operation or alerting the user. - -This will require an additional read of the item for each retry, so limit the total number of retries you allow before completely failing the request loop. - - def update_document_with_retry(item_id, new_data, retries=3): - for attempt in range(retries): - document = get_document(item_id) - current_version = document['Version'] - - result = update_document(item_id, qty_bought, current_version) - - if result is not None: - print("Update succeeded.") - return result - else: - print(f"Retrying update... ({attempt + 1}/{retries})") - - print("Update failed after maximum retries.") - return None - - update_document_with_retry('Bananas', 2) - -Implementing item version control using DynamoDB with optimistic locking and conditional checks is a powerful pattern for ensuring data integrity in distributed applications. While it introduces some complexity and potential performance tradeoffs, it is invaluable in scenarios requiring robust concurrency control. By carefully designing the schema and implementing the necessary checks in your application logic, you can effectively manage concurrent updates and maintain data consistency. - -Additional guidance and strategies for ways to implement version control of your DynamoDB data can be found on the [AWS Database Blog](https://aws.amazon.com/blogs/database/implementing-version-control-using-amazon-dynamodb/). - - - +If you use [DynamoDB global tables](./GlobalTables.html), be aware that global tables use a "last writer wins" reconciliation strategy for concurrent updates. Optimistic locking with version numbers does not work as expected across Regions because a write in one Region may overwrite a concurrent write in another Region without a version check. Design your application to handle conflicts at the application level when using global tables. @@ -167 +84 @@ Efficient bulk operations -Billing and Usage Reports +Optimistic locking