Amélioration des transactions distribuées

l’espace de nom .NET Enterprise Services, puis intégrer manuellement vos assemblys .NET avec COM+. Visual Studio 2005 simplifie ce processus manuel en introduisant un nouvel espace de nom System.Transactions. (Vous trouverez de la documentation sur cet espace de nom à l’adresse http://msdn2.microsoft. com/library/system.transactions.aspx ou dans la section .NET Framework Class Library du site MSDN.) L’espace de nom System.Transactions comporte trois classes principales, utilisables par les développeurs pour gérer les transactions : Transaction, TransactionScope et TransactionManager.

Dans .NET 1.1, vous pouvez employer l’objet Connection pour appeler la méthode BeginTransaction. Lorsque vous utilisez cette méthode sur une connexion SQL Server, l’objet Connection retourne un objet System.Data.SqlClient. SqlTransaction. Vous pouvez ensuite associer cet objet à chacune des commandes qui vont participer à la transaction. Ayez à l’esprit que SQL Server fournit des transactions implicites. Par conséquent, vous avez besoin d’un objet de transaction uniquement pour couvrir la portée de plusieurs commandes. Lorsque vous appelez la méthode BeginTransaction, ADO.NET se sert de votre connexion pour appeler SQL Server et exécuter la commande T-SQL Begin Transaction. Ainsi, le recours à la méthode BeginTransaction impose d’employer séquentiellement le même objet de connexion pour chaque commande qui participera à la transaction et ce type de transaction n’est pas compatible avec les transactions COM+.

La première chose à savoir sur l’utilisation de l’espace de nom System.Transactions est que vous serez encore capable de créer une transaction manuelle sur SQL Server sans la méthode BeginTransaction. Le caractère manuel de la transaction découle du fait que vous codez le début et la fin de celle-ci et que vous l’associez à chaque commande concernée.

L’objet System.Transactions.Transaction de Visual Studio 2005 fournit un moyen d’inclure manuellement une commande dans une transaction. Le code du bloc B du listing 1 contient un exemple de création manuelle d’un objet System.Transactions.CommitableTransaction (l’objet CommitableTransaction est l’une des deux implémentations de la classe de base virtuelle Transaction.) Le code crée un objet Connection et ouvre la connexion. Une fois que vous avez une connexion ouverte sur la base de données, l’objet Connection utilise votre objet Commitable- Transaction pour inscrire une transaction. Il s’agit du début de votre transaction et vous pouvez ensuite exécuter une ou plusieurs commandes de base de données faisant partie intégrante de la transaction en question. Enfin, lorsque vous avez fini d’accéder à la base de données, vous pouvez valider ou annuler votre transaction.

Même si la possibilité d’associer manuellement votre objet Transaction à une connexion est similaire à la logique transactionnelle existante, en toile de fond, vous avez changé le modèle de transaction. Le code du bloc B crée en fait une transaction distribuée qui, dans Visual Studio 2003, nécessiterait Enterprise Services. Vous noterez que ce projet ne référence pas l’espace de nom System.EnterpriseServices. Dans Visual Studio 2005, il suffit d’inclure la bibliothèque System.Transactions dans vos références de projet pour créer une transaction s’étendant à plusieurs sources de données. Le fait de ne pas avoir à utiliser Enterprise Services simplifie votre code et vous évite d’intégrer votre assembly à COM+. Vous pouvez maintenant créer dans .NET une transaction distribuée qui recouvre plusieurs connexions. Souvenez-vous également que même s’il est en sommeil, votre objet Connection doit rester ouvert jusqu’à la fin de la transaction, comme illustré par l’ordre des commandes dans l’exemple de code.

Bien que l’objet System.Transactions.Transaction simplifie la gestion des transactions distribuées, Visual Studio 2005 va plus loin et fournit les outils pour automatiser ce type de transaction. L’objet TransactionScope propose un moyen d’associer automatiquement à la transaction en cours chaque objet de connexion créé au sein de sa portée. Comme le montre le bloc C du listing 1, le code pour l’utilisation de l’objet TransactionScope est, à certains égards, encore plus simple que celui servant à créer manuellement un objet System.Transactions.Transaction. Le code du bloc C commence par utiliser un nouvel élément du langage Visual Basic, la commande Using. Il faut créer systématiquement l’objet TransactionScope dans le contexte d’une commande Using pour être certain que vous avez défini explicitement la portée de la transaction. Après cela, vous pouvez créer et ouvrir autant de connexions que vous le souhaitez et chaque commande s’exécutant dans le contexte de la portée de la transaction active est automatiquement associée à la transaction en cours.

Le code du bloc C pourrait créer des multiples connexions, mais comme l’exemple se contente d’une seule source de données, une seule connexion a été laissée active ici. Le code ouvre la connexion et exécute la commande Update. L’étape suivante vise à définir le statut de la transaction. Notez que ce paramétrage diffère de la validation de la transaction. Lorsque vous employez l’objet TransactionScope, la transaction n’est pas validée tant que l’instruction End Using n’est pas exécutée. En fait, les appels de méthode Complete ou Dispose ne valident ou n’annulent pas votre transaction. Elles indiquent ce qu’il doit se passer lorsque Transaction- Scope arrive au bout. Si vous recourez à un objet Transaction- Scope au lieu d’un objet Transaction, vous n’avez plus besoin d’associer les différentes connexions à votre transaction car .NET crée automatiquement l’association.

Le troisième objet principal dans l’espace de nom System.Transactions, intitulé TransactionManager, est en fait moins conçu pour traiter les transactions que pour fournir aux développeurs une interface avec le coordinateur de transactions distribuées (DTC). L’utilisation de cet objet sort du cadre de cet article, mais sa finalité est de fournir un ensemble de méthodes statiques permettant d’accéder à un ou plusieurs gestionnaires de transactions. Ainsi, les développeurs peuvent enregistrer des utilitaires de gestion des transactions autres que les gestionnaires par défaut proposés par .NET. En d’autres termes, vous pouvez étendre votre coordination des transactions au-delà de COM+.