Partager via

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

  • Article

Un objet mis en pool peut participer à la façon dont COM+ gère son activité dans le pool en implémentant IObjectControl. Lorsqu’un objet mis en pool est créé, il est agrégé en un objet plus grand qui gérera l’objet en appelant les méthodes suivantes sur IObjectControl à des points réguliers du cycle de vie de l’objet :

  • Activer : appelée chaque fois que l’objet est retourné à un client, activé dans un contexte spécifique.
  • Désactiver : appelée chaque fois qu’un objet est libéré par le client ou, dans le cas d’un objet activé par JIT, lorsqu’il est désactivé.
  • CanBePooled : appelé chaque fois qu’un objet doit être retourné au pool général.

L’implémentation d’IObjectControl est facultative, à l’exception des objets transactionnels, qui doivent toujours implémenter CanBePooled pour surveiller l’état des ressources qu’ils contiennent. Toutefois, il est recommandé d’implémenter IObjectControl dans la plupart des cas, car il offre un moyen efficace de gérer le comportement d’un objet mis en pool, comme décrit ci-dessous.

Exécution de l’initialisation Context-Specific

À l’aide de l’option Activer, vous pouvez initialiser l’objet dans le contexte dans lequel il est activé pour un client donné. Par exemple, pour déterminer si l’objet a une affinité de transaction (ses ressources peuvent déjà être inscrites), vous pouvez obtenir l’ID de transaction associé au contexte.

En règle générale, vous utilisez Activatepour effectuer une initialisation cohérente entre toutes les méthodes exposées par l’objet, en le traitant comme la partie spécifique au contexte du constructeur de l’objet.

Nettoyage d’un état client

À l’aide de La désactivation, vous pouvez vous débarrasser de tout état spécifique au client qui peut exister afin que votre objet retourne au pool dans un état complètement générique et puisse ensuite être utilisé par n’importe quel client sans compromettre la sécurité ou l’isolation.

Contrôle de la réutilisation de l’objet

À l’aide de CanBePooled, vous pouvez surveiller l’état interne de votre objet et indiquer s’il est adapté à sa réutilisation. Si CanBePooled renvoie la valeur True et que le pool maximal n’a pas été atteint, l’objet est de nouveau placé dans le pool général. Si CanBePooled retourne False, l’objet est ignoré. Dans le cas des composants transactionnels, le retour de False entraîne l’échec de la transaction actuelle.

En règle générale, vous conservez un membre de données global pour l’objet, et si vous détectez qu’une connexion est incorrecte ou qu’une ressource d’un type quelconque est dans un état incorrect, définissez-le de façon à refléter la situation actuelle et à la renvoyer via CanBePooled.

Si un objet n’implémente pas CanBePooled, les instances continueront d’être réutilisées jusqu’à ce que le niveau maximal du pool soit atteint.

Chaînes du constructeur d’objet COM+

Fonctionnement du regroupement d’objets

Amélioration des performances avec le regroupement d’objets

Regroupement d’objets transactionnels

Configuration requise pour les objets pouvant être mis en pool