Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
La base de données d’inscription COM+ (RegDB) est un gestionnaire de ressources transactionné qui peut participer à des transactions COM+. Cela vous permet d’effectuer des opérations d’administration au sein d’une transaction et d’avoir tous les changements de configuration validés ou abandonnés en tant qu’opération atomique, même sur plusieurs ordinateurs. Dans certaines circonstances, il peut être très utile de le faire, bien qu’il existe un comportement d’isolation et de blocage que vous devez prendre en compte, et l’exécution de tâches d’administration au sein des transactions implique de légères modifications du modèle de programmation d’administration normal.
Avantages de l’exécution d’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 son ensemble, bien qu’il existe certaines ressources de catalogue COM+ non transactionnelles pour lesquelles cela peut ne pas être le cas. (Consultez les 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 sont laissés 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 simultanément. Les écritures persistantes dans RegDB sont une opération relativement coûteuse ; si vous effectuez de nombreuses écritures dans RegDB, vous pouvez obtenir de gros avantages en matière de performances de les faire tout en même temps au lieu de chaque fois que vous appelez 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 particulier de blocage et d’isolation lorsque les opérations d’administration sont effectuées dans les transactions.
Chaque fois qu’un composant qui effectue un travail au sein d’une transaction appelle une méthode qui entraîne une écriture dans le catalogue COM+, tel que SaveChanges, InstallApplicationou InstallComponent, un verrou d’enregistreur est pris sur le code du serveur de catalogue COM+ qui empêchera les autres enregistreurs d’arriver jusqu’à ce que les validations ou abandons de transaction actuels soient effectuées. Autrement dit, les enregistreurs 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 pas les modifications intermédiaires apportées dans la transaction tant que cette transaction n’est pas validée. Tous les composants participant à cette transaction voient les états de données intermédiaires lorsqu’ils lisent des données, mais tous les composants en dehors de la transaction voient ces modifications uniquement une fois la transaction terminée.
Comportement SaveChanges
Pour obtenir le comportement d’isolation décrit ci-dessus, RegDB fournit efficacement un cache qui est géré 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, 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 retourne correctement, vous pouvez appeler StartApplication et activera l’application avec de nouvelles données.
Toutefois, dans une transaction, SaveChanges affecte uniquement le cache, pas 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’existe aucune garantie que StartApplication utilise de nouvelles données ultérieures à SaveChanges retour. 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 de transaction
Si vous effectuez de nombreuses opérations d’administration au sein d’une transaction, il peut s’agir d’une transaction longue. Dans ce cas, la valeur du délai d’expiration de la transaction peut être un problème. Cette valeur est déterminée 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 sur lequel ce composant est en cours d’exécution. Si vous effectuez de nombreuses opérations au sein d’une transaction, il est conseillé de définir le délai d’expiration de la transaction approprié sur une valeur suffisamment longue et, si nécessaire, pour 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.
Note
En cas d’erreur lors de l’abandon d’une transaction, les modifications apportées à ces ressources peuvent ne pas être restauré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 les programmes Add/Remove, auquel cas vous devez le supprimer manuellement.
Récupération en cas de blocage du système
Si un composant effectuant des opérations d’administration au sein d’une transaction devait se bloquer pendant qu’il contient un verrou d’enregistreur sur le code du serveur de catalogue, il 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 au sein des 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 soit créée :
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’aide du catalogue d’administration COM+
-
Vue d’ensemble des objets COMAdmin
-
récupération de collections sur le de catalogue COM+
-
définir les propriétés et enregistrer les modifications apportées au catalogue COM+