Pool d'objet

Article
04/22/2008

Le service COM+ de pool d'objet vous permet de réduire la charge mémoire requise pour créer chaque objet de A à Z. Lorsqu'un objet est activé, il est tiré du pool. Lorsqu'il est désactivé, il regagne le pool en attendant la demande suivante.

Vous pouvez configurer le pool d'objet en appliquant l'attribut ObjectPoolingAttribute à une classe dérivée de la classe System.EnterpriseServices.ServicedComponent.

La procédure permettant d'appliquer l'attribut ObjectPoolingAttribute et de définir ses propriétés est décrite dans la rubrique relative à la création d'un objet pool et à la définition de sa taille et de ses délais.

Le pool d'objet permet de contrôler le nombre de connexions utilisées, alors que le pool de connexion permet de contrôler le nombre maximal atteint. Voici quelques différences importantes entre le pool d'objet et le pool de connexion :

Création. Lorsque vous utilisez le pool de connexion, la création a lieu dans le même thread. Dès lors, si le pool est vide, une connexion est créée à votre intention. Dans le cas du pool d'objet, le pool peut décider de créer un objet. Si toutefois la limite maximale est déjà atteinte, le pool vous attribue l'objet disponible suivant. Ce comportement est crucial lorsque la création d'un objet prend beaucoup de temps, mais que vous n'utilisez pas celui-ci pendant une longue période.
Application de valeurs minimales et maximales. Ceci ne s'applique pas au pool de connexion. La valeur maximale dans le cas d'un pool d'objet est très importante en cas de tentative de mise à l'échelle d'une application. Il se peut que vous deviez procéder au multiplexage de milliers de demandes à un nombre réduit d'objets seulement. (les tests d'évaluation TPC/C en dépendent).

Le pool d'objet COM+ fonctionne de façon presque identique au pool de connexion SQL Client managé pour .NET Framework. Par exemple, la création s'effectue sur un thread différent et des valeurs minimales et maximales sont appliquées.

Remarque :
Les domaines d'application influent sur le comportement du pool d'objet. Sur Windows 2000, si le type d'activation défini pour l'application est Library et s'il existe plusieurs domaines d'application, tous les objets du pool sont créés dans le domaine d'application par défaut et partagés par plusieurs clients. Dans la même situation mais sur Windows XP et sur Windows Server 2003, il existe un seul pool d'objet par domaine d'application. En revanche, avec l'un ou l'autre de ces systèmes d'exploitation, si le type d'activation de l'application est serveur et s'il existe plusieurs domaines d'application, les clients « out-of-process » utilisent le pool d'objet du domaine d'application par défaut.

Les domaines d'application influent sur le comportement du pool d'objet. Sur Windows 2000, si le type d'activation défini pour l'application est Library et s'il existe plusieurs domaines d'application, tous les objets du pool sont créés dans le domaine d'application par défaut et partagés par plusieurs clients. Dans la même situation mais sur Windows XP et sur Windows Server 2003, il existe un seul pool d'objet par domaine d'application. En revanche, avec l'un ou l'autre de ces systèmes d'exploitation, si le type d'activation de l'application est serveur et s'il existe plusieurs domaines d'application, les clients « out-of-process » utilisent le pool d'objet du domaine d'application par défaut.

Remarque :
En général, vous n'avez pas besoin d'appeler DisposeObject à partir du client lorsque vous utilisez les composants de service. Toutefois, cela est nécessaire si vous utilisez le service COM+ de pool d'objet alors que le service d'activation JIT n'est pas activé. Dans ce cas, pour vérifier que vous pouvez retourner l'objet au pool en toute sécurité, COM+ doit être averti du fait que vous avez fini d'utiliser l'objet. En général, si vous prévoyez de ne faire qu'un seul appel à la fois à un objet du pool, il est conseillé d'activer l'activation JIT avec le pool d'objet. Si vous prévoyez d'obtenir une référence et d'y faire plusieurs appels, vous obtiendrez de meilleures performances en utilisant le pool d'objet sans l'activation JIT.

En général, vous n'avez pas besoin d'appeler DisposeObject à partir du client lorsque vous utilisez les composants de service. Toutefois, cela est nécessaire si vous utilisez le service COM+ de pool d'objet alors que le service d'activation JIT n'est pas activé. Dans ce cas, pour vérifier que vous pouvez retourner l'objet au pool en toute sécurité, COM+ doit être averti du fait que vous avez fini d'utiliser l'objet. En général, si vous prévoyez de ne faire qu'un seul appel à la fois à un objet du pool, il est conseillé d'activer l'activation JIT avec le pool d'objet. Si vous prévoyez d'obtenir une référence et d'y faire plusieurs appels, vous obtiendrez de meilleures performances en utilisant le pool d'objet sans l'activation JIT.

Voir aussi

Footer image

Partager via

Pool d'objet

Voir aussi

Tâches

Référence

Concepts

Ressources supplémentaires