Alternatives à l’utilisation de NTFS transactionnel

  • Article

Résumé

Microsoft recommande vivement aux développeurs d’examiner l’utilisation des alternatives décrites (ou dans certains cas, d’examiner d’autres alternatives) plutôt que d’adopter une plateforme d’API qui peut ne pas être disponible dans les versions ultérieures de Windows.

Introduction

TxF a été introduit avec Windows Vista comme un moyen d’introduire des transactions de fichiers atomiques dans Windows. Il permet aux développeurs Windows d’avoir une atomicité transactionnelle pour les opérations de fichier dans les transactions avec un seul fichier, dans les transactions impliquant plusieurs fichiers et dans les transactions couvrant plusieurs sources, telles que le Registre (via TxR) et les bases de données (comme SQL). Bien que TxF soit un ensemble puissant d’API, l’intérêt des développeurs pour cette plateforme d’API a été extrêmement limité depuis Windows Vista, principalement en raison de sa complexité et de diverses nuances que les développeurs doivent prendre en compte dans le cadre du développement d’applications. Par conséquent, Microsoft envisage de déprécier les API TxF dans une future version de Windows afin de concentrer les efforts de développement et de maintenance sur d’autres fonctionnalités et API qui ont plus de valeur pour une plus grande majorité de clients. La section suivante décrit des exemples de méthodes alternatives pour obtenir des résultats similaires à ceux de TxF pour plusieurs types de scénarios d’application.

Alternatives à TxF par scénario

Avec les limitations décrites ci-dessus, les développeurs doivent examiner les alternatives à TxF pour couvrir les scénarios d’application qui ne sont pas respectés par TxF. Voici quelques suggestions d’alternatives aux utilisations courantes de TxF pour les développeurs. Notez que cette liste n’est ni exhaustive ni complète.

Applications mettant à jour un fichier unique avec des données « de type document »

De nombreuses applications qui traitent des données « de type document » ont tendance à charger l’intégralité du document en mémoire, à l’utiliser, puis à l’écrire de nouveau pour enregistrer les modifications. L’atomicité nécessaire ici est que les modifications sont complètement appliquées ou ne sont pas appliquées du tout, car un état incohérent rend le fichier endommagé. Une approche courante consiste à écrire le document dans un nouveau fichier, puis à remplacer le fichier d’origine par le nouveau. Pour ce faire, vous pouvez utiliser l’API ReplaceFile .

Applications effectuant des mises à jour de plusieurs fichiers et/ou de la ruche du Registre

Il existe de nombreuses applications qui doivent effectuer une mise à jour atomique d’un ensemble de fichiers et du Registre. Ce scénario est le plus souvent réalisé par le biais d’une application de programme d’installation, telle que Windows Installer. Pour plus d’informations sur Windows Installer, reportez-vous à Windows Installer.

Applications gérant un ensemble de données structurées

De nombreuses applications gèrent un ensemble de structures de données propriétaires de différents types comme moyen de stocker des données. Un défi important pour ces applications est le processus de maintien de l’intégrité des pointeurs/références internes si une défaillance se produit pendant une opération de mise à jour. La création du mécanisme pour cela est en effet un « problème difficile », et par conséquent, la plupart des applications s’appuient sur un véritable serveur de base de données pour gérer leur jeu de données.

Deux suggestions pour faciliter la gestion des données structurées sont les suivantes :

  • Microsoft fournit la boîte de réception ESE (Extensible Storage Engine) dans Windows pour permettre aux applications d’effectuer des opérations de mise à jour et de récupération des données traitées. Pour plus d’informations sur le moteur de stockage extensible (ESE), consultez https://msdn.microsoft.com/library/gg269259.aspx.
  • Pour les applications qui nécessitent un fournisseur de base de données plus puissant, robuste et évolutif, il est recommandé aux clients d’envisager d’utiliser la fonctionnalité Filestream disponible avec Microsoft SQL Server. Pour plus d’informations sur les flux de fichiers SQL, consultez https://technet.microsoft.com/library/bb933993.aspx.

Applications avec transactions impliquant des fichiers sur un volume NTFS local et des tables dans une base de données SQL externe

Il existe des classes d’applications qui ont des besoins importants en matière de jeux de données ou qui doivent avoir une atomicité transactionnelle dans une opération impliquant une base de données externe et un stockage local. Pour ce scénario, il est vivement recommandé aux développeurs d’envisager d’utiliser des flux de fichiers SQL pour effectuer des opérations de fichier transactionnel. Pour plus d’informations sur les flux de fichiers SQL, consultez https://technet.microsoft.com/library/bb933993.aspx.

Action recommandée de fermeture &

TxF est un ensemble complexe et nuancé d’API qui ne sont pas couramment utilisées par les applications tierces. Avec la possibilité que ces API ne soient pas disponibles dans les versions futures de Windows, et le fait qu’il existe des moyens alternatifs plus simples pour réaliser la plupart des scénarios pour lesquels TxF a été développé, Microsoft recommande vivement aux développeurs d’examiner ces autres moyens au lieu de créer une dépendance sur TxF dans leurs applications.