[Source] .net/C# TransactionScope distribué

Pour citer le guide de quelqu’un d’autre :
Dans le développement réel, exécuter un événement, puis appeler une autre interface pour insérer des données ; s’il y a une exception dans la logique de traitement, alors les données précédemment insérées deviendront des données inutiles,
Ce que nous voulons, c’est pouvoir définir toute la méthode comme une transaction, et la classe TransactionScope fournit une méthode simple qui vous permet de ne pas avoir à interagir avec la transaction elle-même.
pour marquer un bloc de code comme participant à une transaction. L’objet TransactionScope crée une transaction et la définit sur la propriété Current de la classe de transaction.

1. Avantages de TransactionScope
1. Il est plus pratique à utiliser. TransactionScope peut implémenter des transactions implicites, ce qui vous permet d’écrire du code de couche d’accès aux données sans considérer les transactions, mais de contrôler les transactions au niveau métier.
2. Des transactions distribuées peuvent être implémentées, telles que des bases de données croisées ou MSMQ.

2. Inconvénients de TransactionScope
1. Le rapport coût-efficacité n’est pas élevé. Par exemple, vous ne contrôlez les transactions d’une bibliothèque que dans « Portée ». Utiliser « TransactionScope » est un peu gaspilleur.
2. Dans des circonstances normales, tant que vous utilisez « TransactionScope », vous devez configurer MSDTC, installer un pare-feu et ouvrir le port 139. Ce portage ne peut pas être modifié

3. Si vous devez utiliser des transactions distribuées, il faut y réfléchir
1. Cette opération doit-elle forcément être incluse dans la transaction ? Si cette étape n’est pas terminée ou échoue, vaut-il la peine de revenir sur toute la transaction ? N’y a-t-il pas de compensation élégante ou de mesures de tolérance aux fautes ?
2. Combien de points impliquent les transactions distribuées ? Faut-il avoir une longue série d’opérations en temps réel ? Ne pouvez-vous pas simplifier certains points via des opérations de notification ?
3. Après avoir initié une transaction distribuée, avez-vous effectué des opérations indépendantes de la transaction, même si ces opérations n’étaient pas liées à la transaction ? (par exemple, lire des données, calculer, attendre que l’utilisateur retourne un message, attendre le retour d’appel d’autres modules, etc.)
4. Vous n’avez pas compté certaines opérations de lecture dans la transaction, n’est-ce pas ? C’est une erreur facile à commettre lorsque vous inscrivez une opération de sélection dans la transaction.
5. Certaines étapes de votre opération peuvent être exécutées après l’achèvement de toutes les opérations. Ce type d’opération présente des caractéristiques évidentes de notification. Les opérations de notification disent : Je vous donne une notification, et je garantis que la notification vous parviendra ;
Vous devez prendre cet avis et vous assurer qu’il est traité, mais vous n’êtes pas obligé de vous en occuper dès que je vous en informe. Cette opération peut évidemment être réalisée avec une autre tâche.

4. Prêter attention aux points suivants lors de l’utilisation des transactions distribuées
1 : Assurez-vous que la machine participant à la transaction a activé le support distribué des transactions.
2 : Si la machine a activé le pare-feu, vous devez définir le processus MSDTC comme exception.
3 : La machine participant à la transaction ne peut pas traverser le domaine (si elle est inter-domaine, Microsoft n’a pas de solution exacte pour l’instant) ;
4 : Utilisez les transactions distribuées uniquement lorsque vous avez plusieurs bases de données, si c’est la même base de données, il est préférable d’utiliser SqlTransaction.