par exemple. Lorsqu'un blocage se produit, les commandes SQL suivantes sont exécutées avec succès, même si elles ont affecté une transaction SQL qui est après l'annulation. Il semble que cela soit dû à une nouvelle transaction implicite créée sur SQL Server.Bogue de transaction zombie ADO.NET? Comment s'assurer que les commandes ne seront pas exécutées sur une transaction implicite?
Quelqu'un pouvait s'attendre à ce que ADO.NET lève une exception que les commandes sont en cours d'exécution sur une transaction zombie. Cependant, une telle exception n'est pas levée. (Je pense que c'est un bug dans ASP.NET.) En outre, à cause de la transaction zombie, le dernier Dispose()
ignore silencieusement la restauration.
Des idées, comment puis-je m'assurer que personne ne peut exécuter des commandes sur une transaction implicite? Ou, comment vérifier cette transaction est zombie? J'ai trouvé que Commit()
et Rollback()
chèque de transaction zombie, mais je peux les appeler pour un test :)
J'ai aussi trouvé que la lecture aussi IsolationLevel fera le chèque, mais je ne sais pas si simple, appelant transaction.IsolationLevel.ToString();
ne seront pas supprimés par un futur optimiseur. Ou connaissez-vous un autre moyen sûr d'invoquer un getter (sans utiliser de réflexion ou d'émission IL)?
EDIT: Remus Rusanu a souligné que cette situation ne devrait normalement pas se produire. Oui c'est vrai. Cela se produit généralement lorsqu'il y a un bug dans un code. Dans notre cas, il y avait une routine de journalisation dans une instruction finally qui essayait de stocker l'échec dans la base de données. Maintenant, j'essaie de trouver une solution pour détecter de tels bugs dans le futur. Depuis ces bugs sont difficiles à tester. Si ADO.NET vérifie que la transaction fournie est zombie, ce bogue se trouvera beaucoup plus facilement. J'ai trouvé deux possibilités:
- désactiver la création de transactions implicites - Je ne suis pas sûr que ce soit possible.
- Assurez-vous qu'avant d'exécuter des commandes, vérifiez que la transaction zombie est exécutée.
Oui, vous avez raison. Il y avait un bug dans un code. Le bug est corrigé. Maintenant, j'essaie juste de trouver une solution pour éviter de tels bugs. (Cela a été causé par un code de journalisation dans l'instruction finally, qui essayait de consigner le problème dans la base de données.) –