Opérations d’administration COM+ dans les transactions
La base de données d’inscription COM+ (RegDB) est un gestionnaire de ressources traité qui peut participer aux transactions COM+. Cela vous permet d’effectuer des opérations d’administration au sein d’une transaction et d’avoir toutes les modifications de configuration validées ou abandonnées en tant qu’opération atomique, même sur plusieurs ordinateurs. Dans certaines circonstances, cela peut être très utile, bien qu’il existe un comportement d’isolation et de blocage que vous devez prendre en compte, et que l’exécution de tâches d’administration dans les transactions implique de légères modifications du modèle de programmation d’administration normal.
Avantages d’effectuer des opérations d’administration dans les transactions
- **Cohérence des données:**Les opérations d’administration effectuées au sein d’une transaction sont validées ou abandonnées dans l’ensemble, bien qu’il existe certaines ressources de catalogue COM+ non transactionnelles pour lesquelles ce n’est peut-être pas le cas. (Voir Ressources de catalogue COM+ non transactionnelles ci-dessous.)
- **Déploiement cohérent sur plusieurs machines :**Si vous déployez des applications COM+ sur plusieurs serveurs, vous pouvez garantir que tous les serveurs restent avec des configurations identiques.
- **Mise à l’échelle et performances :**Lorsque vous effectuez plusieurs opérations au sein d’une transaction, toutes les écritures dans RegDB sont effectuées en même temps. Les écritures persistantes dans RegDB sont une opération relativement coûteuse ; si vous effectuez de nombreuses écritures dans RegDB, vous pouvez bénéficier d’un grand avantage en matière de performances en les effectuant toutes en même temps au lieu de chaque appel de SaveChanges.
Comportement d’isolation de RegDB
Pour garantir une cohérence des données appropriée et des transactions sérialisables, RegDB applique un comportement de blocage et d’isolation particulier lorsque des opérations d’administration sont effectuées dans les transactions.
Chaque fois qu’un composant qui fonctionne dans une transaction appelle une méthode qui provoquera une écriture dans le catalogue COM+, telle que SaveChanges, InstallApplication ou InstallComponent, un verrou d’enregistreur est pris sur le code du serveur de catalogue COM+ qui empêchera tout autre rédacteur d’arriver jusqu’à ce que la transaction actuelle soit validée ou abandonnée. Autrement dit, les rédacteurs ne peuvent entrer que s’ils ont l’affinité de transaction correcte et participent à la transaction actuelle.
Les lecteurs ne sont pas bloqués. Toutefois, les données que les lecteurs voient ne reflètent aucune modification intermédiaire apportée dans la transaction tant que cette transaction n’a pas été validée. Tous les composants participant à cette transaction voient des états de données intermédiaires lorsqu’ils lisent des données, mais tous les composants en dehors de la transaction ne voient ces modifications qu’une fois la transaction terminée.
SaveChanges Comportement
Pour atteindre le comportement d’isolation décrit ci-dessus, RegDB fournit efficacement un cache qui est activé par les composants au sein de la transaction. Cela modifie le comportement de la méthode SaveChanges .
Normalement, sans la présence d’une transaction, toutes les modifications en attente sont écrites dans le catalogue lorsque vous appelez SaveChanges, et SaveChanges ne retourne pas tant que toutes les écritures ne sont pas terminées. Cela garantit que si un appel à SaveChanges est retourné avec succès, vous pouvez appeler StartApplication et qu’il activera l’application avec de nouvelles données.
Toutefois, au sein d’une transaction, SaveChanges affecte uniquement le cache, et non la base de données RegDB elle-même, et SaveChanges retourne immédiatement si toutes les modifications ont été validées sur RegDB. Il n’est pas garanti que StartApplication utilise de nouvelles données après le retour de SaveChanges . Si vous devez appeler StartApplication dans ce contexte, il est conseillé d’attendre un certain temps avant de le faire.
Période de Time-Out transaction
Si vous effectuez de nombreuses opérations d’administration dans une transaction, il peut s’agir d’une transaction de longue durée. Dans ce cas, la valeur du délai d’expiration de la transaction peut être un problème. Cela est déterminé par la valeur de délai d’expiration de la transaction définie pour le composant qui lance la transaction ou par le paramètre de délai d’attente à l’échelle de l’ordinateur pour l’ordinateur sur lequel ce composant s’exécute. Si vous effectuez de nombreuses opérations au sein d’une transaction, il est conseillé de définir le délai d’expiration de transaction approprié sur une valeur suffisamment longue et, si nécessaire, de restaurer le paramètre d’origine lorsque vous avez terminé.
Ressources de catalogue COM+ non transactionnelles
Le Registre, le système de fichiers et Windows Installer (MSI) sont des ressources de catalogue COM+ qui ne sont pas transactionnelles.
Notes
En cas d’erreur qui annule une transaction, les modifications apportées à ces ressources peuvent ne pas être annulées.
En cas d’erreur lors de l’installation d’une application COM+ existante à partir d’un fichier .msi, l’application n’apparaît pas dans le composant logiciel enfichable Services de composants, mais elle peut apparaître dans Ajout/Suppression de programmes, auquel cas vous devez la supprimer manuellement.
Récupération en cas de blocages système
Si un composant effectuant des opérations d’administration au sein d’une transaction se bloquait alors qu’il détient un verrou d’enregistreur sur le code du serveur de catalogue, cela empêcherait tout le monde d’apporter des modifications au catalogue. Si cela se produit, vous pouvez effacer le verrou sur le catalogue en arrêtant et en redémarrant l’application système.
Script avec un objet TransactionContext
Un moyen simple d’effectuer des opérations d’administration dans les transactions consiste à utiliser un objet TransactionContext pour contrôler la transaction. Par exemple, le script Visual Basic suivant montre comment ajouter transactionnellement deux nouvelles applications afin que les deux applications ou aucune application ne soient créées :
Dim txctx
Dim cat
Dim apps
Dim app1
Dim app2
WScript.Echo "Starting"
Set txctx = CreateObject("TxCtx.TransactionContext")
Set cat = txctx.CreateInstance("COMAdmin.COMAdminCatalog")
Set apps = cat.GetCollection("Applications")
Set app1 = apps.Add
app1.Value("Name") = "Test App #1"
apps.SaveChanges
Set app2 = apps.Add
app2.Value("Name") = "Test App #2"
apps.SaveChanges
WScript.Echo "Ending"
txctx.Commit
Rubriques connexes
-
Exemple d’introduction à l’utilisation du catalogue d’administration COM+
-
Définition des propriétés et enregistrement des modifications apportées au catalogue COM+