TransactionScope vs Transaction dans LINQ to SQL

Question

Quelles sont les différences entre le classique motif de transaction dans LINQ to SQL comme:

using(var context = Domain.Instance.GetContext())
{
    try
    {
        context.Connection.Open();
        context.Transaction = context.Connection.BeginTransaction();
        /*code*/
        context.Transaction.Commit();
    }
    catch
    {
        context.Transaction.Rollback();
    }         
}

vs l'objet TransactionScope

using (var context = Domain.Instance.GetContext())
using (var scope = new TransactionScope())
{
    try
    {
        /*code*/
        scope.Complete();
    }
    catch
    {
    }
}

Answer 1

Il convient de noter que lors de l'utilisation de l' TransactionScope il n'est pas nécessaire pour l' try/catch construire que vous avez. Il vous suffit de faire appel Complete sur le champ, afin de valider la transaction, lorsque le champ d'application est quittée.

Cela étant dit, TransactionScope est généralement un meilleur choix, car il vous permet d'imbriquer des appels à d'autres méthodes qui pourraient exiger une transaction sans avoir à passer l'état des transactions autour de.

Lors de l'appel d' BeginTransaction sur le DbConnection objet, vous devez passer que l'objet de la transaction autour si vous voulez effectuer d'autres opérations dans le cadre d'une même opération, mais dans une méthode différente.

Avec TransactionScope, tant que le champ existe, elle prendra en charge tout ce qui s'enregistre auprès de l'actuel Transaction sur le fil, ce qui rend votre code plus propre, et plus maintenable.

En plus de cela, vous avez l'avantage supplémentaire d'être en mesure d'utiliser d'autres ressources qui peuvent participer à des transactions, et pas seulement la connexion à la base de données.

Il convient de noter que, dans les situations où vous avez besoin pour profiter au maximum de vos connexions et opérations de base de données, vous ne pouvez utiliser TransactionScope; même contre une seule base de données, vous exécutez la possibilité de le Coordinateur de Transactions Distribuées utilisé et ayant la transaction tourné dans une transaction distribuée (même pour une seule connexion de base de données).

Dans ces cas, tandis que troubler votre conception, vous pouvez envisager l'adoption d'un spécifique à la connexion de transactions autour de.

Ou, si vous savez que vous allez utiliser une ressource constante (et sur le même sujet), vous pouvez créer une classe de référence-nombre de votre connexion ou la transaction.

Vous devez créer une classe que sur la construction, crée votre ressource/incrémente le compteur. Elle permettrait également de mettre en oeuvre IDisposable (dans lequel vous décrémenter/presse/commettre/abandonner lorsque le compte à rebours est à zéro), et de stocker le nombre dans une variable qui a ThreadStaticAttribute lui est appliquée.

Cela vous permet de séparer la gestion des transactions à partir de la logique du code, et de se tenir toujours sur une unique ressource assez efficacement (au lieu de dégénérer en une transaction distribuée).

Answer 2

Linq2SQL utilisera une transaction implicite. Si l'ensemble de vos mises à jour sont effectuées au sein d'un seul Soumettre, vous ne pouvez pas besoin de gérer l'opération vous-même.

À partir de la documentation (l'emphase est mienne):

Lorsque vous appelez SubmitChanges, LINQ to SQL vérifie si l'appel est à la portée d'une Transaction ou si la Transaction de propriété (IDbTransaction) est définie par l'utilisateur commencé transaction locale. Si elle ne trouve ni transaction, LINQ to SQL démarre une transaction locale (IDbTransaction) et l'utilise pour exécuter le SQL généré des commandes. Lorsque toutes les commandes SQL ont été réalisés avec succès, LINQ to SQL valide la transaction locale et les retours.

Answer 3

Une grande différence (leçon apprise à la dure) – TransactionScope utilise MS DTC pour la gestion des transactions.

Si votre application doit gérer les transactions de base de données uniquement, et pas de services ou d'appels à distance sont impliqués, vous pouvez ignorer les problèmes potentiels liés à MS DTC par l'aide de la transaction natif aux bases de données (DbTransactions).

Answer 4

TransactionScope fournitures gestion unifiée pour tous les gestionnaires de ressources (SQL server, active directory, système de fichiers, ...). En outre, on peut écrire propre gestionnaire de ressources: le code qui détecte l'étendue de transaction, rejoindre sa fonctionne exactement comme SQL server n': commet ou d'annuler les modifications apportées à l'instar d'autres participants de l'opération. J'ai cru que TransactionScope est dominant et j'ai oublié de MS SQL native transactions jusqu'a échoué dans l'énorme piège: Windows Server 2008 WEB Edition est livré avec limitée Distributed Transaction Coordinator Service et de l'étendue de la Transaction fonctionne sur un seul ordinateur uniquement. Votre ASP.NET application échoue sur ce système si IIS et SQL server sont installés sur des ordinateurs différents. Prendre en compte le fait que la plupart des fournisseurs de domaine de l'approvisionnement Windows Server WEB edition et SQL server sont sur des serveurs distincts. Cela signifie, que vous devez travailler avec les autochtones de transactions à l'aide de transactions explicites de gestion ...

Answer 5

Je crois qu'ils sont fondamentalement le même que la classe TransactionScope servira d'interface avec le ADO.NET la connexion sous-jacente de créer et de valider ou d'annuler la transaction. Que la classe TransactionScope a été créé pour rendre le travail avec ADO.NET la persistance d'un nettoyeur.

Edit: Clarifier mon intervention, en ce qui concerne casperOne de plus il est TransactionScope qui permettra de créer de la transaction et la connexion sera alors voir la transaction, qui a été créé par le TransactionScope et de l'utiliser car il est disponible.