11
votes

Deadlocks de transaction, comment concevoir correctement?

Donc, je travaille sur ce projet-cadre d'entité qui sera utilisé comme type de DAL et lors de l'exécution de tests de stress (à commencer quelques mises à jour sur des entités via le thread () et que je reçois ces:

_innerexception = {"La transaction (ID de processus 94) a été imputée sur des ressources de verrouillage avec un autre processus et a été choisi comme victime de blocage. Rerun la transaction."}
Voici un exemple de la manière dont j'ai implémenté les méthodes de mes classes: xxx
et: xxx p > Évidemment, le code ici pourrait probablement être meilleur, mais je suis plutôt un débutant d'EF. Mais je pense que mon problème est plutôt un problème de conception avec le contexte.
Je me souviens de quelqu'un ici mentionnant que si mon contexte n'est pas partagé, je ne rencontrerai pas ces problèmes d'impasse.
Cela ne semble pas me "partagé" pour moi comme je fais un en utilisant de nouvelles annonces () dans chaque méthode, alors que dois-je changer pour le rendre plus robuste?
Ce dal sera utilisé dans un service Web exposé sur Internet (après l'examen du CODE de Cour), donc je n'ai aucun contrôle sur le montant que cela sera stressé et que beaucoup d'instances différentes pourraient souhaiter mettre à jour la même entité.
merci!

c# .net multithreading deadlock entity-framework-4.1

1 commentaires

Vous devrait partager un contexte par demande HTTP pour diverses raisons. Pas plus, rarement plus court.

3 Réponses :

2
votes

Le contexte est ce qui donne à l'entité sa capacité à parler à la base de données, sans contexte, il n'y a pas de concept de ce qui se passe où. Spinning un contexte, est donc une sorte de grosse affaire et il occupe beaucoup de ressources, y compris les ressources externes comme la base de données. Je crois que votre problème est la commande « nouveau », puisque vous auriez plusieurs threads essayant de tourner et saisir la même ressource de base de données, ce qui serait certainement une impasse.
Votre code que vous avez posté il semble être un anti-modèle. La façon dont elle regarde, vous avez votre contexte et l'entité spinning sortir du champ, alors que vos objets semblent dépôt CRUD relativement rapidement à persister pour beaucoup plus de temps.
La façon dont les entreprises que je l'ai mis en œuvre Entité traditionnellement fait exactement dans le sens opposé - le contexte est créé et est maintenu aussi longtemps que l'a assemblage besoin de base de données et les objets du référentiel CRUD sont créés et meurent en microsecondes .
Je ne peux pas dire où vous avez obtenu votre affirmation du contexte ne sont pas partagés de sorte que je ne sais pas quelles circonstances cela a été dit sous, mais il est tout à fait vrai que vous ne devez pas partager le contexte dans les assemblées. parmi même ensemble, je ne vois aucune raison pour laquelle vous ne seriez pas avec combien de ressources qu'il faut pour démarrer un contexte, et combien de temps il faut pour le faire. Le contexte entité est assez lourd, et si vous deviez faire votre travail de code actuel en allant monothread Je suppose que vous verriez un peu de performance absolument atroce.
Alors, ce que je recommande est plutôt factoriser ce que vous avez Créer (BackEndEntites contexte) et Mise à jour (contexte de BackEndEntities) , ont alors votre fil maître (celui faire tous ces fils de l'enfant) créer et maintenir un contexte de BackEndEntities à transmettre à ses enfants. Assurez-vous également que vous vous débarrasser de votre AgentController et OrderController s l'instant où vous avez terminé avec eux et jamais, jamais, jamais les réutiliser en dehors d'une méthode. La mise en œuvre d'une bonne inversion du cadre de contrôle comme Ninject ou StructureMap peut en faire beaucoup plus facile.
1 commentaires Merci très utile. Je vais ensuite accéder au refacteur selon vos conseils. :)
6 votes La liberté de l'impasse est un problème assez dur dans un grand système. Cela n'a rien à voir avec EF en soi. raccourcir la durée de vie de vos transactions réduit les impasses, mais elle introduit des incohérences de données. Dans ces endroits où vous étiez une mauvaise manipulation, vous détruisez maintenant des données (sans aucune notification). Alors choisissez votre durée de vie de votre contexte et votre durée de vie de la transaction en fonction de la transaction logique, non en fonction des considérations physiques. Allumez l'isolement d'instantané. Cela prend totalement des transactions de lecture hors de l'équation. Pour écrire des transactions, vous devez trouver un commande de verrouillage. Souvent, c'est le moyen le plus simple de verrouiller pessimisme et à un niveau supérieur. Exemple: utilisez-vous toujours des données dans le contexte d'un client? Prenez une mise à jour sur ce client comme première instruction de vos transactions. Qui fournit une liberté totale de blocage en sérialisant l'accès à ce client. 2 commentaires L'isolement d'instantané a résolu tout. Je peux exécuter 200 threads de mon application de test .NET en utilisant cette DAL, mettant à jour les mêmes entités et aucun d'entre eux ne s'est écrasé. Est-il courant que la plupart des blocages sont sur des transactions de lecture? Cela signifie-t-il que SQL Server gère mieux les mises à jour de masse que la masse sélectionne? Non, des blocages peuvent se produire sur une charge de travail impliquant des écritures. Les impasses disparaissent dans votre cas sont une coïncidence. Peut-être que, parce que vous avez de nombreuses petites transactions qui sont en lecture seule. Ceux-ci sont entièrement supprimés de l'image. 9 votes La raison des morceaux de chale n'est pas votre code mais qui est dû à EF qui utilise sérialisisable pour le niveau d'isolation de transaction par défaut. sérialisable est le verrouillage le plus restreint possible, cela signifie que vous êtes par défaut en optage par défaut dans le plus restrictif. Niveau d'isolation, et vous pouvez vous attendre à beaucoup de verrouillage! La solution consiste à spécifier un autre transaction en fonction de l'action que vous souhaitez effectuer. Vous pouvez entourer vos actions EF avec quelque chose comme ceci: xxx En savoir plus sur ce numéro: http://blogs.msdn.com /b/diego/archive/2012/04/01/tips-a-avoid-deadlocks-in-entity-Framework-applications.aspx http://blogs.u2u.be/diederik /post/2010/06/29/transactions-and-connections-inentity-framework-40.aspx http://blog.Accrégnéintelligence.com/2012/04/sql-server-transaction-isolation-and.html https://serverfault.com/questions / 319373 / SQL-DEA DLocking-and-calming-out - presque constamment 0 commentaires

Articles qui pourrait vous intéresser : Calculer la différence dans l'échelle d'évaluation alphabétique Ignorer la propriété de l'interface utilisateur Swagger Comment détruire les éléments dynamiques du panneau dans le script Unity C # Entity Framework Core 3.1 avec NetTopologySuite.Geometries.Point: SqlException: la valeur fournie n'est pas une instance valide de la géographie du type de données