2009-06-09 11 views
4

Je fais quelques opérations dans linq2sql qui doivent être exécutées dans une transaction. Cependant, certaines des méthodes que j'utilise à l'intérieur de la transaction utilisent aussi linq2sql et s'exécutent dans leur propre transaction (la transaction interne est exécutée dans une procédure stockée). Cela me donne l'exceptionComment utiliser plusieurs, transactions imbriquées?

[TransactionInDoubtException: The transaction is in doubt.] 
    System.Transactions.TransactionStateInDoubt.EndCommit(InternalTransaction tx) +76 
with the inner exception 
[SqlException (0x80131904): There is already an open DataReader associated with this Command which must be closed first.] 

si j'utilise MultipleActiveResultSets pour SQL Server, je place obtenir l'exception

[SqlException (0x80131904): The transaction operation cannot be performed because there are pending requests working on this transaction.] 

Quelqu'un at-il l'expérience de travailler avec linq2sql et transactionscopes de cette façon?

Répondre

0

Je sais que nous avons rencontré ce problème sur le projet sur lequel je travaille actuellement et je sais qu'il a quelque chose à voir avec LinqToSql qui génère le fichier dbml de la mauvaise façon en travaillant avec un sproc. Nous devions le faire manuellement pour le faire fonctionner. LinqToSql a apparemment renvoyé ISingeResult du sproc et cela a généré l'erreur. Je n'ai pas été celui qui a corrigé l'erreur mais je sais que cela a quelque chose à voir avec ça.

Plus d'info: http://www.west-wind.com/weblog/posts/246222.aspx

2

Ce fut une « face-paume » moment pour moi, mais étant donné que je voyais ce comportement exact, et il n'a pas tout de suite m'a frappé, je pensais que je serais aller de l'avant et poster cette possibilité:

je voyais ce comportement quand j'avais un ensemble TransactionScope pour READUNCOMMITTED:

using (TransactionScope scope = new TransactionScope(TransactionScopeOption.Required, 
     new TransactionOptions { IsolationLevel = IsolationLevel.ReadUncommitted }) 

et mon LINQ to SQL appelai une procédure stockée pour retourner les résultats du proc. La face-palm est celle dans le proc lui-même, on peut spécifier l'indice SQL WITH (NOLOCK), il n'y a donc pas besoin d'encapsuler la requête Linq to SQL dans la portée de transaction ReadUncommitted. (Au moins dans mon cas)

1

Je suppose que vous essayez de lire certaines données et de les modifier à la volée (pendant que la lecture est en cours).
Dans ce cas, l'option la plus simple consiste à lire toutes les données en premier (par exemple, en utilisant la méthode d'extension IEnumerable <> .ToList()), puis effectuer toutes les opérations sur les données.

+0

Cela a fini par être mon problème avec un problème similaire ci-dessus, donc +1 de moi :) – James

0

Je sais que c'est un vieux fil de discussion mais c'est le hit de haut niveau pour google sur cette erreur, donc j'ai pensé que ça vaudrait la peine d'ajouter ma réponse. Dans mon cas, j'utilisais Entity Framework donc je ne suis même pas sûr que ça s'applique mais même si certaines personnes utilisant EF viendraient probablement ici. Dans mon cas, c'était parce que j'appelais un proc stocké et que je ne faisais rien avec les lignes retournées. Comme EF n'avait pas lu les lignes, c'était "l'opération ouverte". Ma solution consistait simplement à ajouter First() à la fin de chaque appel de procédure:

myentities.CallMyStoredProc(A, B, C).First(); 
Questions connexes