Configuration requise pour les objets pouvant être mis en pool
Les objets pouvant être regroupés doivent répondre à certaines exigences pour permettre à un seul objet instance d’être utilisé par plusieurs clients.
Sans état
Pour maintenir la sécurité, la cohérence et l’isolation, les objets pouvant être regroupés ne doivent contenir aucun état spécifique au client. Vous pouvez gérer n’importe quel état par client à l’aide d’IObjectControl, en effectuant une initialisation spécifique au contexte avec IObjectControl::Activate et en nettoyant l’état du client avec IObjectControl::D eactivate. Pour plus d’informations, consultez Contrôle de la durée de vie et de l’état des objets.
Aucune affinité de thread
Les objets pouvant être regroupés ne peuvent pas être liés à un thread particulier ; sinon, les performances pourraient être désastreuses. Pour cette raison, les objets pouvant être regroupés ne peuvent pas être marqués pour s’exécuter dans le modèle d’appartement ; ils doivent courir dans l’appartement multithread ou l’appartement neutre. En outre, les objets pouvant être regroupés ne doivent pas utiliser le stockage local des threads et ne doivent pas agréger le marshaleur de threads libres. Pour plus d’informations sur le threading dans COM+, consultez Modèles de thread COM+.
Notes
Les environnements de développement Microsoft Visual Basic 6.0 et antérieurs ne peuvent créer que des composants de modèle d’appartement. Toutefois, dans Visual Basic .NET, les composants peuvent être regroupés.
Aggregatable
Les objets pouvant être regroupés doivent prendre en charge l’agrégation, autrement dit, ils doivent prendre en charge la création en appelant CoCreateInstance avec un argument pUnkOuter non NULL. Lorsque COM+ active un objet mis en pool, il crée un agrégat pour gérer la durée de vie de l’objet mis en pool et appeler des méthodes sur IObjectControl. Pour plus d’informations sur l’écriture d’objets agrégables, consultez Agrégation.
Composants transactionnels
Les objets pouvant être regroupés qui participent à des transactions doivent inscrire manuellement des ressources managées. Lorsqu’il est mis en pool, si votre objet contient une ressource managée telle qu’une connexion de base de données, le gestionnaire de ressources ne peut pas s’inscrire automatiquement dans une transaction lorsque l’objet est activé dans un contexte donné. Par conséquent, l’objet lui-même doit gérer la logique de détection de la transaction, en désactivant l’inscription automatique du gestionnaire de ressources et en inscrivant manuellement toutes les ressources qu’il détient. En outre, un objet en pool transactionnel doit refléter l’état actuel de ses ressources dans les valeurs de paramètre IObjectControl::CanBePooled. Pour plus d’informations, consultez Regroupement d’objets transactionnels.
Implémenter IObjectControl pour gérer la durée de vie de l’objet
Les objets pouvant être regroupés doivent implémenter IObjectControl, même s’il n’est pas strictement nécessaire de le faire. Toutefois, les composants transactionnels qui sont mis en pool doivent implémenter IObjectControl. Ces composants doivent surveiller l’état des ressources qu’ils détiennent et indiquer quand ils ne peuvent pas être réutilisés ; quand IObjectControl::CanBePooled retourne false, une transaction est vouée à l’échec. Pour plus d’informations, consultez Contrôle de la durée de vie et de l’état des objets.
Restrictions linguistiques
Les composants développés à l’aide de Microsoft Visual Basic 6.0 et versions antérieures ne peuvent pas être regroupés, car ces composants seront threadés sur le modèle d’appartement. Toutefois, dans Visual Basic .NET, les composants peuvent être regroupés.
Composants hérités
Tant qu’ils ne sont pas transactionnels et qu’ils sont conformes aux exigences précédentes appropriées, les composants peuvent être regroupés, même s’ils n’ont pas été spécifiquement écrits en tenant compte de la fonctionnalité de regroupement à l’esprit. Il n’est pas nécessaire d’implémenter IObjectControl ; un composant qui ne le fait pas ne participe tout simplement pas à la gestion de sa durée de vie. Si IObjectControl::CanBePooled n’est pas implémenté, l’objet continue d’être réutilisé jusqu’à ce que le pool atteigne la taille maximale.
Rubriques connexes