Quels sont les problèmes liés à l’utilisation des transactions dans une base de données ?

Question

Depuis ce post.Un problème évident est l’évolutivité/performance.Quels sont les autres problèmes que l’utilisation des transactions va provoquer ?

Pourriez-vous dire qu'il existe deux ensembles de problèmes, un pour les transactions à long terme et un pour les transactions à court terme ?Si oui, comment les définiriez-vous ?

MODIFIER:Le blocage est un autre problème, mais l'incohérence des données peut être pire, selon le domaine d'application.En supposant qu'il s'agisse d'un domaine digne d'une transaction (bancaire, pour utiliser l'exemple canonique), la possibilité d'un blocage s'apparente davantage à un coût à payer pour garantir la cohérence des données, plutôt qu'à un problème d'utilisation des transactions, ou seriez-vous en désaccord ?Si oui, quelles autres solutions utiliseriez-vous pour garantir la cohérence des données sans blocage ?

Answer 1

Cela dépend beaucoup de l'implémentation transactionnelle dans votre base de données et peut également dépendre du niveau d'isolation des transactions que vous utilisez.Je suppose ici une "lecture répétable" ou supérieure.Garder les transactions ouvertes pendant une longue période (même celles qui n'ont rien modifié) oblige la base de données à conserver les lignes supprimées ou mises à jour de tables changeant fréquemment (juste au cas où vous décideriez de les lire) qui pourraient autrement être supprimées.

De plus, l’annulation des transactions peut être très coûteuse.Je sais que dans le moteur InnoDB de MySQL, l'annulation d'une transaction importante peut prendre BEAUCOUP plus de temps que sa validation (nous avons vu une annulation prendre 30 minutes).

Un autre problème concerne l’état de connexion à la base de données.Dans une application distribuée et tolérante aux pannes, vous ne pouvez jamais vraiment savoir dans quel état se trouve une connexion à une base de données.Les connexions aux bases de données avec état ne peuvent pas être maintenues facilement car elles peuvent échouer à tout moment (l'application doit se souvenir de ce qu'elle était en train de faire et de le refaire).Les apatrides peuvent simplement être reconnectés et la commande (atomique) est réémise sans (dans la plupart des cas) rompre l'état.

Answer 2

Vous pouvez obtenir des blocages même sans utiliser de transactions explicites.D'une part, la plupart des bases de données relationnelles appliqueront une transaction implicite à chaque instruction que vous exécutez.

Les blocages sont fondamentalement causés par l'acquisition de plusieurs verrous, et toute activité impliquant l'acquisition de plusieurs verrous peut se bloquer avec toute autre activité impliquant l'acquisition d'au moins deux verrous identiques à la première activité.Dans une transaction de base de données, certains des verrous acquis peuvent être conservés plus longtemps qu'ils ne le seraient autrement -- jusqu'à la fin de la transaction, en fait.Plus les verrous sont maintenus longtemps, plus le risque de blocage est grand.C’est pourquoi une transaction de plus longue durée a plus de chances d’aboutir à une impasse qu’une transaction de plus courte durée.

Answer 3

Un problème avec les transactions est qu'il est possible (peu probable, mais possible) d'obtenir des blocages dans la base de données.Vous devez comprendre comment fonctionne votre base de données, se verrouille, effectue des transactions, etc. afin de déboguer ces problèmes intéressants/frustrants.

-Adam

Answer 4

Je pense que le problème majeur se situe au niveau du design.À quel(s) niveau(s) de mon application dois-je utiliser les transactions.

Par exemple, je pourrais :

• Créer des transactions au sein de procédures stockées,
• Utilisez l'API d'accès aux données (ADO.NET) pour contrôler les transactions
• Utiliser une forme de restauration implicite plus haut dans l'application
• Une transaction distribuée en (via DTC / COM+).

L’utilisation de plusieurs de ces niveaux dans la même application semble souvent créer des problèmes de performances et/ou d’intégrité des données.