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. # Lock:transactionid L'événement `Lock:transactionid` se produit lorsqu'une transaction attend un verrou au niveau ligne. **Topics** + [Versions de moteur prises en charge](#apg-waits.locktransactionid.context.supported) + [Contexte](#apg-waits.locktransactionid.context) + [Causes probables de l'augmentation du nombre d'événements d'attente](#apg-waits.locktransactionid.causes) + [Actions](#apg-waits.locktransactionid.actions) ## Versions de moteur prises en charge Ces informations sur les événements d’attente s’appliquent à toutes les versions d’Aurora PostgreSQL. ## Contexte L'événement `Lock:transactionid` se produit lorsqu'une transaction tente d'acquérir un verrou de niveau ligne qui a déjà été accordé à une transaction exécutée en même temps. La session qui présente l'événement d'attente `Lock:transactionid` est bloquée à cause de ce verrou. Une fois la transaction de blocage terminée dans une instruction `COMMIT` ou `ROLLBACK`, la transaction bloquée peut se poursuivre. La sémantique de contrôle de simultanéité multiversion d'Aurora PostgreSQL garantit l'absence de blocage des lecteurs par les dispositifs d'écriture, et vice versa. Pour que des conflits se produisent au niveau ligne, les transactions de blocage et les transactions bloquées doivent émettre des instructions conflictuelles des types suivants : + `UPDATE` + `SELECT … FOR UPDATE` + `SELECT … FOR KEY SHARE` L'instruction `SELECT … FOR KEY SHARE` est un cas particulier. La base de données utilise la clause `FOR KEY SHARE` pour optimiser les performances de l'intégrité référentielle. La présence d'un verrou de niveau ligne sur une ligne peut bloquer les commandes `INSERT`, `UPDATE` et `DELETE` sur d'autres tables qui font référence à la ligne. ## Causes probables de l'augmentation du nombre d'événements d'attente Un événement trop fréquent est généralement dû à des instructions `UPDATE`, `SELECT … FOR UPDATE` ou `SELECT … FOR KEY SHARE` combinées aux conditions suivantes. **Topics** + [Forte simultanéité](#apg-waits.locktransactionid.concurrency) + [État Idle in transaction (Transaction inactive)](#apg-waits.locktransactionid.idle) + [Transactions de longue durée](#apg-waits.locktransactionid.long-running) ### Forte simultanéité Aurora PostgreSQL peut utiliser une sémantique de verrouillage détaillée de niveau ligne. La probabilité de conflits au niveau ligne augmente lorsque les conditions suivantes sont réunies : + Une charge de travail à forte simultanéité se dispute les mêmes lignes. + La simultanéité augmente. ### État Idle in transaction (Transaction inactive) Parfois, la colonne `pg_stat_activity.state` affiche la valeur `idle in transaction`. Cette valeur apparaît pour les sessions qui ont entamé une transaction, mais qui n'ont pas encore émis de commande `COMMIT` ou `ROLLBACK`. Si la valeur `pg_stat_activity.state` n'est pas `active`, la requête affichée dans `pg_stat_activity` est la plus récente à avoir été exécutée. La session de blocage ne traite pas activement une requête, car une transaction ouverte comporte un verrou. Si une transaction inactive a acquis un verrou au niveau ligne, cela peut empêcher d'autres sessions de l'acquérir. Cette condition entraîne l'apparition fréquente de l'événement d'attente `Lock:transactionid`. Pour diagnostiquer le problème, examinez la sortie de `pg_stat_activity` et `pg_locks`. ### Transactions de longue durée Les transactions qui s'exécutent depuis longtemps comportent des verrous pendant longtemps. Ces verrous de longue durée peuvent bloquer l'exécution d'autres transactions. ## Actions Le verrouillage de ligne correspond à un conflit entre les instructions `UPDATE`, `SELECT … FOR UPDATE` ou `SELECT … FOR KEY SHARE`. Avant de rechercher une solution, déterminez quand ces instructions sont exécutées sur la même ligne. Utilisez ces informations pour choisir une des stratégies décrites dans les sections suivantes. **Topics** + [Réagissez à une forte simultanéité](#apg-waits.locktransactionid.actions.problem) + [Réagissez aux transactions inactives](#apg-waits.locktransactionid.actions.find-blocker) + [Réagissez aux transactions de longue durée](#apg-waits.locktransactionid.actions.concurrency) ### Réagissez à une forte simultanéité En cas de problème lié à la simultanéité, essayez l'une des techniques suivantes : + Réduisez la simultanéité dans l'application. Par exemple, réduisez le nombre de sessions actives. + Implémentez un groupe de connexions. Pour savoir comment regrouper des connexions à l'aide de RDS Proxy, consultez [Proxy Amazon RDS pour Aurora](rds-proxy.md). + Concevez l'application ou le modèle de données de manière à éviter les instructions `UPDATE` et `SELECT … FOR UPDATE` conflictuelles. Vous pouvez également réduire le nombre de clés étrangères accessibles par les instructions `SELECT … FOR KEY SHARE`. ### Réagissez aux transactions inactives Si `pg_stat_activity.state` indique `idle in transaction`, utilisez les stratégies suivantes : + Si possible, activez la validation automatique. Cette approche empêche les transactions de bloquer d'autres transactions en attendant une instruction `COMMIT` ou `ROLLBACK`. + Recherchez les chemins de code qui ne contiennent pas d'instruction `COMMIT`, `ROLLBACK` ou `END`. + Assurez-vous que la logique de gestion des exceptions de votre application comporte toujours un chemin vers une `end of transaction` valide. + Assurez-vous que votre application traite les résultats des requêtes après avoir mis fin à la transaction avec `COMMIT` ou `ROLLBACK`. ### Réagissez aux transactions de longue durée Si des transactions de longue durée sont à l'origine de l'apparition fréquente de `Lock:transactionid`, essayez les stratégies suivantes : + N'utilisez pas de verrous de ligne dans les transactions de longue durée. + Limitez la longueur des requêtes en implémentant la validation automatique chaque fois que possible.