Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Verrouillage pessimiste avec les transactions DynamoDB
Les transactions DynamoDB proposent une approche « tout ou rien » pour les opérations groupées. Lorsque vous l'utilisezTransactWriteItems, DynamoDB surveille tous les éléments de la transaction. Si un élément est modifié par une autre opération au cours de la transaction, l'ensemble de la transaction est annulé et DynamoDB renvoie un. TransactionCanceledException Ce comportement constitue une forme de contrôle de simultanéité pessimiste, car les modifications simultanées conflictuelles sont évitées plutôt que détectées a posteriori.
Quand utiliser les transactions pour le verrouillage
Les transactions conviennent parfaitement lorsque :
Vous devez mettre à jour plusieurs éléments de manière atomique, soit dans la même table, soit dans plusieurs tables.
Votre logique métier nécessite une sémantique du tout ou rien : soit toutes les modifications aboutissent, soit aucune n'est appliquée.
Les exemples courants incluent le transfert de fonds entre comptes, la passation de commandes qui mettent à jour à la fois l'inventaire et les tableaux de commandes, et l'échange d'objets entre joueurs au cours d'une partie.
Compromis
- Coût d'écriture plus élevé
Pour les éléments jusqu'à 1 Ko, les transactions consomment 2 WCU par élément (une pour préparer, une pour valider), contre 1 WCU pour une écriture standard.
- Limite d'articles
Une transaction peut inclure jusqu'à 100 actions sur une ou plusieurs tables.
- Sensibilité aux conflits
Si un élément de la transaction est modifié par une autre opération, l'ensemble de la transaction échoue. Dans les scénarios de forte contention, cela peut entraîner de fréquentes annulations.
Mise en œuvre
L'exemple suivant permet TransactWriteItems de transférer le stock entre deux articles de manière atomique. Si un autre processus modifie l'un des éléments au cours de la transaction, l'ensemble de l'opération est annulé.
import boto3 client = boto3.client('dynamodb') def transfer_inventory(source_id, target_id, quantity): try: client.transact_write_items( TransactItems=[ { 'Update': { 'TableName': 'Inventory', 'Key': {'ItemID': {'S': source_id}}, 'UpdateExpression': 'SET QuantityLeft = QuantityLeft - :qty', 'ConditionExpression': 'QuantityLeft >= :qty', 'ExpressionAttributeValues': { ':qty': {'N': str(quantity)} } } }, { 'Update': { 'TableName': 'Inventory', 'Key': {'ItemID': {'S': target_id}}, 'UpdateExpression': 'SET QuantityLeft = QuantityLeft + :qty', 'ExpressionAttributeValues': { ':qty': {'N': str(quantity)} } } } ] ) return True except client.exceptions.TransactionCanceledException as e: print(f"Transaction canceled: {e}") return False
Dans cet exemple, l'expression de condition vérifie que l'inventaire est suffisant, mais qu'aucun attribut de version n'est nécessaire. DynamoDB annule automatiquement la transaction si un élément de la transaction est modifié par une autre opération entre les phases de préparation et de validation. C'est ce qui permet un contrôle de concurrence pessimiste : les modifications simultanées contradictoires sont évitées par la transaction elle-même.
Note
Vous pouvez combiner des transactions avec un verrouillage optimiste en ajoutant des vérifications de version sous forme d'expressions de condition supplémentaires. Cela fournit un niveau de protection supplémentaire mais n'est pas obligatoire pour que la transaction détecte les conflits.
Pour de plus amples informations, veuillez consulter Gestion des flux complexes avec des transactions Amazon DynamoDB.