J'ai une application C # multithreadée dans laquelle chaque thread a son propre ensemble de connexions DB. Chaque thread utilise des transactions de transaction / DTC. Parfois, je reçois une "transaction a abandonné" l'exception. Ce n'est pas à partir d'un délai car il se produit en moins de 2 secondes de démarrer la transaction.
Voici le StackTrace:
à System.Transactions.TransactionStateAserted.begincommit (interneTransaction TX, Boolean AsyncCommouver, AsyncCallback asynccallback, objet asyncstate) à System.Transactions.committableTransaction.commit () à System.transactions.transactionsCope.internalDispose () à Système.transactions.transactionsCope.Dispose () à myNamespace.callingmethod ()
Il se passe très rarement, disons une fois dans 100 000 transactions.
Environnement: Windows Server 2003 .NET 2.0 Se connecte à SQLSERVER 2005
Des idées sur la raison pour laquelle cela se produit? Merci!
6 Réponses :
Cette pile d'appels est-elle de votre innerexception intérieure? Je vous obtiens ces exceptions, il y a généralement (pas toujours, bien que) une inturnéréxception avec plus d'informations.
Mon pari serait sur une impasse de base de données.
Oui, c'était la plus intérieure exception. J'ai accès à des traces d'impasse et aucun n'a été trouvé pendant cette période.
Vous pouvez créer une mémoire de mémoire, l'instruction peut être trouvée ici. http: // blogs.msdn.com/b/joncole/archive/2007/03/29/Creatting-A-Process-Memory-Dump.aspx
Ensuite, vous pouvez vérifier avec WINDBG pour révéler l'exception racine de ce problème. Il y a beaucoup d'informations utiles sur la manière d'utiliser WINDBG Vérifiez l'exception gérée.
Dans le temps moyen, vous pouvez utiliser SQL Profiler pour surveiller si une erreur SQL s'est produite à l'heure à laquelle l'exception a été lancée.
J'aime cette idée. Je vais à nouveau essayer de recréer cela dans Dev et obtenir une réponse à ce problème.
Si vous avez la mémoire de mémoire, je peux le vérifier pour vous. Vous pouvez le mettre sur le dossier public SkyDrive.
Comme l'a dit Andreas, regardez les Innerexceptions. Branchez également le profileur SQL et recherchez toutes les impasses / terminer.
Je pense que cela est attribué à l'instabilité du réseau. Il est très peu fréquent et n'a pas élevé sa tête laide depuis quelques mois maintenant.
Si l'un d'entre vous face à ce problème, veuillez noter que j'ai réussi à trouver la solution et le problème. Dans le fichier de configuration de l'application, une propriété pour la chaîne de connexion manquante qui était "Enrôtre" ,.
Plus tôt La chaîne de connexion était = maintenant la chaîne de connexion mise à jour est =
Ce problème peut également se produire s'il existe une transaction interne qui n'a pas été commise. Si vous placez une périmètre de transaction dans un bloc d'utilisation et il n'y a pas de validation, le support de fermeture annulera toutes les transactions au cours du dispositif. Cela peut conduire à la transaction using (var outerScope = new TransactionScope())
{
using (var innerScope = new TransactionScope())
{
// Some operations to be done inside a transaction
//innerScope.Complete()
} // Dispose is called here and rolls back both inner and outer scope
outerScope.Complete();
}
Est-ce que les journaux d'erreur SQL, DTC ou OS ont-ils des détails supplémentaires?
Toute entrées dans les journaux d'événements avec cet horodatage?
Boîte de production, il est donc difficile d'obtenir des informations sans ruban rouge. Je vais voir si je peux obtenir quelque chose du journal des événements, c'est plus facile. Merci!
Rien dans les journaux d'événement du système d'exploitation. Sur les journaux SQL.
Rien dans les journaux SQL. Sur les métriques de performance pour voir si cela détient des indices.
Aucun indices des métriques de performance.
Cette pile d'appels est-elle vraiment de l'exception la plus intérieure? Lorsque vous obtenez cette exception, il y a généralement une ingénieur exceptionnelle qui contient plus d'informations sur le problème réel.