Comme je le disais précédemment, cet espace de nom au travers de sa classe « TransactionScope » représente un bon compromis. En effet, il s'agit d'un système intelligent hybride qui utilise par défaut une transaction locale et qui peut utiliser une transaction distribuée supportée par MSDTC. Ce système de gestion de transaction est donc capable de promouvoir une transaction dite « simple » vers une transaction distribuée si une des conditions suivantes est remplie :

• Utilisation d'objets différents faisant intervenir de nouveaux contextes transactionnels
• Transport du flot d'exécution vers un autre « AppDomain »
• Interaction avec une un autre « Resource Manager »

Il va de soit que le temps de promotion d'une transaction simple vers une transaction distribuée a un coût sur les performances générales de la transaction (le temps de la promotion justement), mais c'est le prix de la généricité dans ce cas.

Quelques particularités importantes :

• L'instance de la classe « TransactionScope » est souvent utilisée via un bloc « Using » chargé de la libération des ressources (TransactionScope est « IDisposable »)
• Dans ce cadre là, il n'est pas utile d'annuler (et impossible car la méthode n'existe pas) la transaction dans le bloc. Le non-appel à la méthode « Complete » et la sortie du bloc « using » suffisent
• Le TimeOut d'exécution est de 60 secondes
• Possibilité d'imbriquer les Scope transactionnels les uns avec les autres
• Possibilité d'abonnement à deux événements intéressants
  • System.Transactions.Transaction.Current.TransactionCompleted : transaction validée
  • System.Transactions.TransactionManager.DistributedTransactionStarted : promotion d'une transaction simple vers une transaction distribuée. Dans ce cas, il faut bien faire attention au fait que la transaction est promue après le traitement de l'événement.

Voici un exemple d'utilisation :On se rend bien compte de l'apport de transparence à l'utilisation d'un « TransactionScope ». Par la suite, il est possible d'accéder aux propriétés de la transaction ambiante via « System.Transactions.Transaction.Current ».

Le fonctionnement d'un gestionnaire de ressources distribuées tel que Microsoft Distributed Transaction Coordinator (MSDTC) est le suivant :

• L'application appelle le Transaction Manager pour créer la transaction (gestion du contexte transactionnel, de l'atomicité et de la durabilité)
• Tous les composants intervenants sont enrôlés dans la transaction ambiante
• Le Transaction Manager garde de manière séquentielle un log afin que la décision finale de validation ou d'invalidation soit durable et garantie
• Au final, si tous les RM impliqués sont prêts alors la transaction est validée et le log est effacé
• Sinon le Transaction Manager diffuse un ordre d'annulation à tous les « Resources Managers » impliqués

Il faut savoir que WCF supporte les transactions « natives » et « WS-Atomic » (standard). Ce dernier protocole définit comment implémenter des transactions sur la base d'un commit à deux phases :

• Phase 1
  • Le coordinateur demande à chaque « Resource Manager » (RM) de se préparer au commit
  • Chaque RM vote pour valider ou invalider la transaction
  • Le coordinateur collecte les votes et prend une décision (commit ou rollback)
• Phase 2
  • Le coordinateur demande à chaque RM de valider ou d'invalider
  • Si un RM doit valider, il accuse réception de l'achèvement ou bien réalise le rollback
  • Le coordinateur attend les AR des RM pour indiquer que la transaction s'est terminée correctement

Ce mécanisme permet donc d'implémenter des transactions de type « tout ou rien » avec des systèmes faiblement couplés dispersés sur différentes plateformes. WCF fournit une implémentation de WS-AT construite sur MSDTC. Il est possible de configurer WS-AT via les propriétés du DTC. Pour cela, il faut registrer la dll suivante pour faire apparaitre l'onglet qui va bien !

• Regasm.exe /codebase wsatui.dll (« C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin »)

Finalement, au beau milieu de la réalisation de l'article, je me suis dit qu'il serait dommage de réaliser la couche l'accès aux données avec le Fx 3.5 sans utiliser Linq To SQL. Je m'y suis donc attelé afin de mettre en place 3 choses : la sélection éventuellement filtrée, l'ajout et la suppression.

Linq To Sql est une implémentation d'un petit mapper objet-relationnel basé sur ADO.NET, intégré à Visual Studio 2008 et ciblant pour l'instant exclusivement les bases SQL Server. Il permet donc de faire la liaison entre des classes et des tables en base de données de manière quasi transparente pour le développeur. Je dis quasi transparente, car il faudra quand même décrire le mapping existant soit à la main sous la forme d'un fichier de mapping ou bien avec des attributs, soit en utilisant le Designer intégré à Visual Studio 2008. Voici un exemple de requêtage que j'ai pu utiliser au travers d'une classe générique :Je reviendrai techniquement sur cette partie un peu plus loin dans cet article. Ce que j'apprécie particulièrement dans l'utilisation de Linq To Sql et de la syntaxe Linq en général c'est que l'on décrit précisément ce que l'on veut obtenir, mais pas comment faire pour l'obtenir. C'est donc l'implémentation sous-jacente de Linq qui se charge du comment (Linq To Object, Linq To Xml, Linq To Sql, etc.) contrairement à ce que l'on faisait avant en ouvrant précisément une connexion et en exécutant tel ordre SQL par exemple. L'idée d'apporter intrinsèquement et nativement au langage le requêtage sans passer par un Framework compliqué est brillante.

Vous trouverez sur le Web de nombreuses explications sur l'utilisation de Linq To Sql et je ne m'étendrai pas davantage là-dessus. Je vous recommande donc le plan suivant pour une mise en jambe rapide :

• Le Training Kit Visual Studio 2008
• Les vidéos réalisées par Mitsuru Furuta (Microsoft) réalisé lors du Tour de France Accès aux données
• Les quelques articles rédigés par Scott Guthrie sur Linq To SQL et son intégration avec ASP.NET

Une chose était importante pour moi dans cet exemple : le fait de pouvoir utiliser mes propres définitions de contrat de données et non pas celles générées par le Designer Graphique de Linq To Sql. Or, le Designer Linq To SQL ne permet pas cette séparation stricte. J'ai donc du réaliser cela à la main et j'ai choisi la décoration par attribut à la définition d'un fichier de mapping car plus simple à faire à la main.

Non non, il ne s'agit pas d'une marque de motos bien connue des spécialistes, mais d'un service nouvellement offert par les plateformes Windows Vista et bientôt Windows Server 2008 seules. Il permet de rendre les transactions disponibles au niveau des composants systèmes tels que NTFS (Transactional NTFS ou TxF) et la base de registres (Transactional Registry ou TxR).

Le KTM est aussi dépendant d'une autre API Système, le Common Log File System (CLFS) assurant la gestion des logs, rendant ainsi possible une gestion transactionnelle. Dans le cadre de cet article, nous travaillerons seulement sur TxF. TxF permet ainsi aux opérations de gestion de fichiers sur une partition NTFS de participer à une transaction ambiante, qu'elle soit distribuée ou non. Par exemple :

• Mise à jour d'un fichier (contenu et attributs)
• La création d'un fichier et l'insertion en base de données
• La création de fichiers sur plusieurs machines
• Participation à une transaction avec plusieurs autres Resource Managers transactionnels (SGBD, MSMQ)
• Scénario supporté : un écrivain – plusieurs lecteurs concurrents et consistants. Les lecteurs transactionnels voient toujours une version consistante du fichier accédé. Attention, il n'y a pas de support pour les mises à jour concurrentes sur différentes transactions. La conséquence est que TxF n'est pas la solution adéquate pour les scénarios avec des utilisateurs multiples.

Comme il s'agit d'une API que je qualifierai de « bas niveau », cela nécessite de manipuler des structures et des fonctions C. Nous ferons alors beaucoup de P/Invoke. Voici la logique de l'utilisation :

• Création de la transaction ambiante via un TransactionScope
• Récupération d'un « Transacted File Handle » en écriture en lieu et place d'un simple handle
• TxF verrouille l'accès
  • Toute opération de modification sur le fichier en dehors de cette transaction recevra une erreur
  • Tout lecteur transactionnel sur le fichier recevra une erreur à l'ouverture dès lors que le fichier est ouvert dans un cadre non transactionnel. Ce tableau issu de la documentation du MSDN résume bien les verrouillages :
     

    

    Verrouillages TxF

     
  • En d'autres termes, TxF fournit un niveau d'isolation de type « Read-Committed ». Cela signifie qu'en mode transactionnel :
    • Un écrivain unique verra la version la plus récente ainsi que tous les changements réalisés dans le cadre de cette transaction.
    • Un lecteur verra seulement la dernière version validée qui existait à l'ouverture du fichier. Le lecteur est donc complètement isolé des modifications des écrivains transactionnels.
• Travail sur le handle transactionnel
• Fermeture du handle transactionnel (avant de faire le commit)
• Validation / invalidation de la transaction ambiante

WCF utilise des « Policy Assertions » afin de contrôler et paramétrer le flot transactionnel. Ces dernières sont spécifiées par des attributs à la fois sur les contrats et les services, mais aussi par configuration.

Les transactions peuvent être initiées par le client ou par le service accédé. Dans le cas d'une transaction initiée par le client, nous utiliserons l'attribut « TransactionFlow » sur le contrat de service afin de préciser la capacité d'un service à accepter une transaction provenant d'un client et à se paramétrer en conséquence. Bien entendu, cette notion n'est pas applicable aux méthodes « OneWay » du fait de leurs natures asynchrones.D'autres paramètres viennent influencer le comportement transaction d'un service. L'attribut « ServiceBehavior » applicable sur la classe qui implémente les méthodes d'un contrat de service possède des propriétés intéressantes :

• TransactionAutoCompleteOnSessionClose » (false)
  • Toute transaction incomplète sera complétée quand la session fermera. Si true, le channel entrant devra gérer les sessions
• « ReleaseServiceInstanceOnTransactionComplete » (true)
  • Précise si l'instance du service doit être libérée lorsque la transaction est complétée. Si true, tout nouveau message entraine la création d'une nouvelle instance
• « TransactionIsolationLevel » (Unspecified)
  • Spécifie le niveau d'isolation de la transaction au sein du service
• « TransactionTimeout » (60 secondes)
  • Durée maximale pendant laquelle la nouvelle transaction doit être complétée

Enfin, l'attribut « OperationBehavior », applicable sur l'implémentation d'une méthode en particulier, permet aussi de paramétrer une transaction via les propriétés :

• Propriété « TransactionScopeRequired » (false)
  • Indique si l'opération doit s'exécuter au sein d'une transaction
• Propriété « TransactionAutoComplete » (true)
  • Auto-commit de la transaction si l'opération s'exécute avec succès

Maintenant que nous avons succinctement passé en revue l'ensemble des technologies utilisées dans cet article, analysons un peu le code de la solution.