Pool d'objets

Le service COM+ de pool d'objets 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'objets en appliquant l'attribut ObjectPoolingAttribute à une classe dérivée de la classe System.EnterpriseServices.ServicedComponent.

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

• Création. Lorsque vous utilisez le pool de connexions, 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'objets, le pool peut décider de créer un nouvel 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 des nombres minimaux et maximaux. Ceci ne s'applique pas au pool de connexions. La valeur maximale dans le cas d'un pool d'objets 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'objets COM+ fonctionne de façon presque identique au pool de connexions 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'objets. Dans Microsoft 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 avec Microsoft Windows XP et Windows Server 2003, il y a un seul pool d'objets 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'objets du domaine d'application par défaut.

L'exemple suivant définit des limites de taille et de délai pour la classe TestObjectPooling :

<ObjectPooling(MinPoolSize := 2, MaxPoolSize := 5, _
CreationTimeout := 20000)> _
Public Class TestObjectPooling 
Inherits ServicedComponent
      Public Sub Perform ()
            ' Method contents go here.
      End Sub 
      Public Overrides Sub Activate()
            ' Called when removed from the pool.
      End Sub 
      Public Overrides Sub Deactivate()
            ' Called before deactivating or placing back in pool.
      End Sub 
      Public Overrides Function CanBePooled() As Boolean
            ' Called after Deactivate. Indicate your vote here.
            Return True
      End Function 
End Class 
[C#]
[ObjectPooling(Enabled=true, MinPoolSize=2, MaxPoolSize=5, CreationTimeOut=20000)]
public class TestObjectPooling : ServicedComponent
{
      public void Perform ()
      {
         // Method contents go here.
      }
      public override void Activate()
      {
         // Called when removed from the pool.
      }
      public override void Deactivate()
      {
         // Called before deactivating or placing back in pool.
      }
      public override bool CanBePooled()
      {
         // Called after Deactivate. Indicate your vote here.
         return true;
      }
}

Client

Public Class App
      Overloads Public Shared Sub Main(args() As String)
            Dim order As New TestObjectPooling()
            order.Perform()
            ' To return the object to the object pool, use DisposeObject.
            ' This returns the object to the pool and allows it to be reused.
            ' If this call is not made, the garbage collector returns it to the pool
            ' in a non-deterministic fashion, which hinders performance
            ' of an application that depends on object pooling to conserve 
            ' expensive resources. 
            ServicedComponent.DisposeObject (order)
      End Sub
End Class
[C#]
public class App
{
      public static int Main(string[] args)
      {
            TestObjectPooling order = new TestObjectPooling();
            order.Perform();
            /* To return the object to the object pool, use DisposeObject.
            This returns the object to the pool and allows it to be reused. 
            If this call is not made, the garbage collector returns it to the pool
            in a non-deterministic fashion, which hinders performance 
            of an application that depends on object pooling to conserve 
            expensive resources. */
            ServicedComponent.DisposeObject (order);
      }
}

**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'objets 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'objets. 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'objets sans l'activation JIT.

Voir aussi

Résumé des services COM+ disponibles | ObjectPoolingAttribute | System.EnterpriseServices, espace de noms