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 fournissent all-or-nothing une approche 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'intégralité de la transaction est annulée et DynamoDB renvoie un. TransactionCanceledException Ce comportement fournit une forme de contrôle de simultanéité pessimiste, car les modifications simultanées contradictoires sont empêchées plutôt que détectées a posteriori.
Quand utiliser les transactions pour le verrouillage
Les transactions conviennent bien lorsque :
Vous devez mettre à jour plusieurs éléments de manière atomique, soit au sein d'une même table, soit entre plusieurs tables.
Votre logique métier nécessite de la all-or-nothing sémantique : soit tous les changements sont réussis, soit aucun n'est appliqué.
Les exemples courants incluent le transfert de fonds entre comptes, les commandes qui mettent à jour à la fois l'inventaire et les tables de commandes, et l'échange d'articles entre joueurs dans un jeu.
Compromis
- Coût d'écriture plus élevé
Pour les éléments allant jusqu'à 1 Ko, les transactions WCUs en consomment 2 (un pour préparer, un pour valider), contre 1 WCU pour une écriture standard.
- Limite d'articles
Une seule transaction peut inclure jusqu'à 100 actions réparties 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 très litigieux, 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 qu'il existe un inventaire suffisant, mais 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 pessimiste de la simultanéité : les modifications simultanées contradictoires sont empêchées par la transaction elle-même.
Note
Vous pouvez associer des transactions à 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 nécessaire pour que la transaction détecte les conflits.
Pour de plus amples informations, veuillez consulter Gestion des flux complexes avec des transactions Amazon DynamoDB.