Partager via

Regroupement d’objets transactionnels

  • Article

Les composants transactionnels qui doivent être regroupés ont des exigences particulières.

Inscription manuelle de ressources

Les objets pouvant être regroupés qui participent à des transactions doivent inscrire manuellement des ressources managées. Si un objet contient des ressources managées entre des clients, il n’existe aucun moyen pour le gestionnaire de ressources de s’inscrire automatiquement dans une transaction lorsque l’objet est activé dans un contexte donné.

L’objet lui-même doit gérer la logique de détection de la transaction, désactiver l’inscription automatique du gestionnaire de ressources et inscrire manuellement toutes les ressources qu’il détient. Les étapes de cette opération sont spécifiques au gestionnaire de ressources que vous utilisez. Si vous devez effectuer une inscription manuelle, consultez la documentation de votre gestionnaire de ressources.

Comme décrit ci-dessous, les objets peuvent être regroupés avec l’affinité de transaction pendant qu’une transaction est active et peuvent être activés avec l’affinité de transaction s’ils sont appelés par un client associé à cette transaction. Avant d’inscrire des ressources, vous devez d’abord case activée pour l’affinité transactionnelle. Si l’objet a été extrait du pool spécifique à cette transaction, il a déjà effectué un travail dans cette transaction et inscrit ses ressources.

Désactivation de l’inscription automatique

L’inscription automatique doit être désactivée une fois la ressource acquise, généralement dans le constructeur de l’objet. Autrement dit, vous désactivez l’inscription automatique, puis vous vous connectez.

La désactivation de l’inscription automatique peut parfois être une procédure subtile, en particulier dans le cas de fournisseurs d’accès aux données en couches. L’inscription automatique est parfois couplée à un regroupement de connexions, comme avec ODBC, et parfois pas, comme avec OLE DB. Vous devrez peut-être vous assurer que l’inscription automatique est désactivée à plusieurs niveaux de fournisseurs.

Implémentation d’IObjectControl

Les objets pouvant être regroupés qui participent à des transactions doivent surveiller l’état actuel des ressources qu’ils détiennent. Si l’objet détecte qu’il est dans un état non réutilisable(par exemple, si une connexion est incorrecte), il doit retourner False pour IObjectControl::CanBePooled. Cela aura pour effet d’ignorer l’objet instance et de faire annuler la transaction actuelle.

pools Transaction-Specific

Un pool d’objets est généralement homogène, et tout objet mis en pool qui n’est pas en cours d’utilisation peut être retourné à n’importe quel client. La seule exception à cette règle est dans le cas des objets transactionnels, pour lesquels le regroupement d’objets est optimisé. Lorsque le client qui demande un objet a une transaction associée, COM+ analyse le pool à la recherche d’un objet disponible déjà associé à cette transaction. Si un objet avec une affinité transactionnelle est trouvé, il est retourné au client ; sinon, un objet du pool général est retourné.

De cette manière, des sous-pools spéciaux sont conservés contenant des objets ayant une affinité pour une transaction particulière. Lorsque la transaction est validée ou abandonnée, ces objets sont retournés au pool général sans affinité de transaction, prêts à être utilisés par n’importe quel client.

Pour cette raison, lorsque votre composant inscrit manuellement ses ressources managées dans une transaction, il doit d’abord case activée pour voir si elles sont déjà inscrites. Si c’est le cas, il n’est pas nécessaire de s’inscrire.

Chaînes du constructeur d’objet COM+

Contrôle de la durée de vie et de l’état des objets

Fonctionnement du regroupement d’objets

Amélioration des performances avec le regroupement d’objets

Configuration requise pour les objets pouvant être mis en pool