TransactionScope, linq et étrange gestionnaire de transactions problème (HRESULT: 0x8004D024)

Question

J'ai des méthodes de niveau de service, qui apportent peu de changements à la base de données et je veux qu'ils utilisent le contrôle des transactions. Ces méthodes peuvent faire ce qui suit: - Fonctionnalité LINQ SubmitChanges() - Appels à StoredProcedures

Les utilisateurs de composants peuvent combiner un ensemble de ces opérations élémentaires en quelque chose de plus grand.

Je vois qu'il ya bien TransactinScope de classe et d'essayer de l'utiliser:

using (TransactionScope transaction = new TransactionScope()) 
{ 
    content = repository.CreateBaseContent(content); 
    result = repository.CreateTreeRelation(content, parent.Id, name); 
    transaction.Complete(); 
} 

public baseContent CreateBaseContent(baseContent content) 
{ 
     EntityContext.baseContents.InsertOnSubmit(content); 
     EntityContext.SubmitChanges(); 

     return content; 
} 

public CreateTreeRelation (params) 
{ 
// do StoredProcedure call here via LINQ 
} 

Mon hypothèse était que sur les couches extérieures, il serait possible d'ajouter un autre niveau de la portée de la transaction. Au lieu de cela, j'ai l'erreur suivante:

Le gestionnaire de transactions a désactivé sa prise en charge pour les transactions à distance/réseau. (Exception de HRESULT: 0x8004D024)

J'utilise la même machine (Vista Ultimate) pour MS SQL 2005 et le serveur de développement Microsoft. Des tests unitaires tout fonctionne bien. Même lorsque TransactionScope a commenté.

je tentais de jouer avec la sécurité des DTC (http://support.microsoft.com/kb/899191) et quand je me mis à acccept toutes les transactions entrantes et sortantes, j'ai message d'erreur suivant:

Erreur HRESULT E_FAIL a été renvoyé par un appel à un COM composant.

Au cours de débogage, je découvert que dans SubmitChanges, Contexte Linq entité a transaction immobilière IS NULL (!!), et a System.Transactions.Transaction.Current transaction ouverte

Answer 1

problème est arrivé parce que Linq datacontext a été créé avant TransactionScope .

La solution consistait à ajouter un contrôle de transaction propre au contexte de données LINQ.

Connection.Open() 
Transaction = Connection.BeginTransaction(); 

et les compteurs pour maintenir les appels imbriqués.

Answer 2

Je pense que vous pouvez également utiliser TransactionScope aussi longtemps que vous transmettez les datacontexts la même connexion que vous .Open.

Un autre problème que vous rencontrez avec TransactionScope est qu'il ne se soucie pas de savoir si la chaîne de connexion est la même, faire une seconde .Open va élever la transaction à une transaction distribuée. Et puis vous devez faire face à la configuration associée, et aussi le fait qu'il n'utilise pas la transaction légère qui est ce qui est nécessaire pour ce cas.