Utiliser Nolock Indicateur dans EF4?

Je suis un développeur sur une équipe d'outils dans l'org SQL chez Microsoft. Je ne suis en aucun cas autorisé à faire une déclaration officielle et je suis sûr qu'il y a des gens qui en savent plus sur ces choses que moi. Néanmoins, je vais offrir une règle de base amicale, le long du thème de "l'optimisation prématurée est la racine de tout mal":

N'utilisez pas Nolock (ou tout autre indice de requête à ce sujet) jusqu'à ce que vous ayez à faire. Si vous avez une instruction SELECT qui possède un plan de requête décent, et qu'il fonctionne bien lorsqu'il y a très peu d'autre charge sur le système, mais il ralentit ensuite lorsque d'autres requêtes accèdent à la même table, essayez d'ajouter des indices Nolock. Mais comprenez toujours que lorsque vous faites, vous courez le risque d'obtenir des données incohérentes. Si vous écrivez une application critique de mission qui fait bancaire en ligne ou contrôle un aéronef, cela peut être inacceptable. Toutefois, pour de nombreuses applications, la vitesse de conforme vaut le risque. Évaluer au cas par cas, cependant. Ne les utilisez pas simplement Willy Nillly partout sur la place.

Si vous choisissez d'utiliser NOLOCK, j'ai blogué une solution en C # à l'aide des méthodes d'extension, de sorte que vous puissiez facilement modifier une requête LINQ pour utiliser NOLOCK CONSEILS. Si vous pouvez l'adapter à EF4, veuillez publier votre adaptation.

EF4 n'a pas de manière intégrée pour le faire si EF4 génère toutes vos questions.

Il existe des moyens d'utiliser des procédures stockées ou un modèle de requête en ligne plus étendu, cependant, cela peut consommer du moins pour le moins.

Je crois (et je ne parle pas pour Microsoft sur ceci) que la mise en cache est la solution prévue de Microsoft pour éclaircir la charge sur le serveur dans les sites EF4. Ayant lu non engagé (ou Nolock) intégré dans un cadre créerait des problèmes imprévisibles pour le comportement attendu de l'EF4 lorsque 2 contextes sont exécutés en même temps. Cela ne signifie pas que votre situation a besoin de ce niveau de concurrence.

On dirait que vous avez été demandé à Nolock sur tous les éléments sélectionnés. Bien que je suis d'accord avec une affiche antérieure que cela peut être dangereux si vous avez des transactions qui doivent être des transactions, je ne suis pas d'accord qui rend automatiquement le DBA un muppet. Vous pouvez simplement exécuter un CMS totalement cool pour des lectures sales. Vous pouvez modifier le niveau d'isolation sur toute votre base de données pouvant avoir le même effet.

Le DBA peut avoir recommandé NOLOCK pour les opérations qui n'étaient que sélectionnées (qui conviennent bien, surtout s'il y a une ou une ormise en train d'être mal à la fois et de faire des vidages de données dus). La chose la plus drôle sur ce commentaire de Muppet est que la pile débordement est exécutant SQL Server en mode de lecture non engagée. Devinez que vous avez besoin de trouver ailleurs pour obtenir des réponses pour vos problèmes alors?

Parlez à votre DBA sur la possibilité de la définir sur un niveau de base de données ou envisager une stratégie de mise en cache si vous n'en avez besoin que dans quelques endroits. Le Web est apatride après tout ce que la simultanément peut souvent être une illusion de toute façon, sauf si vous y adressez la DIRECLTY.

Info sur les niveaux d'isolation

Bien que ce soit un pita majeur à faire, vous pouvez toujours déposer votre SQL dans une procédure stockée et obtenir les fonctionnalités dont vous avez besoin (ou être contraint). C'est définitivement un hack cependant!

Ayant travaillé avec EF4 depuis plus d'un an maintenant, je vais offrir que l'utilisation de procédures stockées pour des tâches spécifiques est pas un piratage et absolument nécessaire pour la performance sous certaines situations.

Notre plate-forme obtient beaucoup de la circulation via notre site Web, nos API et nos flux de données ETL. Nous utilisons EF principalement sur notre site Web, mais également pour certains processus de back-end. Parfois, ef fait un excellent travail avec sa génération de requête, parfois c'est terrible. Vous devez examiner les requêtes générées, les charger dans l'analyseur de requête et décider si vous feriez mieux d'écrire l'opération d'une autre manière (procédure stockée, etc.).

Si vous constatez que vous devez effectuer des données disponibles via EF et avez besoin Nolocks , vous pouvez toujours créer des vues avec le nolock indice inclus et exposer le Voir à ef au lieu de la table sous-jacente. La même chose peut être faite avec des procédures stockées. Ces méthodes sont probablement un peu plus faciles lorsque vous utilisez la première approche du code.

Mais je pense qu'une erreur de nombreuses personnes gagnent avec EF, c'est croire que le modèle d'objet EF doit faire mapper directement sur le modèle physique (table) de la base de données. Ce n'est pas et c'est là que votre DBA entre en jeu. Laissez-le concevoir votre modèle physique et vous travaillez ensemble pour résumer votre modèle de données logique mappé sur votre modèle d'objet dans EF.