Gestion de la durée de vie des modules de données
Remonter à Structure du serveur d'applications
Le pool d'objet vous permet de créer un cache des modules de données qui sont partagés par leurs clients, ce qui économise les ressources. Son fonctionnement dépend du type du module de données exposé et du protocole de connexion.
Durée de vie d'un module serveur
Une application serveur créée en utilisant la technologie DataSnap contient une instance de TDSServerClass. La propriété LifeCycle de cette instance spécifie la durée de vie du module serveur. Les valeurs possibles sont :
- Invocation
- Serveur
- Session (définie par défaut)
Invocation
Le paramètre de durée de vie Invocation indique au serveur DataSnap de créer une nouvelle instance du module de données spécifié pour chaque requête client. Si le module de données expose des méthodes serveur, une nouvelle instance est alors créée pour chaque appel de méthode. Après l'appel, les modules de données sont automatiquement détruits.
Serveur
Si le paramètre de durée de vie Serveur est choisi, le serveur DataSnap crée puis réutilise les instances des modules de données pour chaque client connecté. Serveur est utile quand le module de données a été conçu pour être "client-agnostique" et il peut servir tout client qui l'utilise. Tous les modules de données créés avec ce paramètre sont libérés quand le serveur DataSnap est arrêté.
Session
L'option Session est définie par défaut et a été conçue pour être la meilleure alternative dans la plupart des circonstances. En mode Session, le serveur DataSnap crée une instance de module de données par client. Le module de données existe tant que le client est connecté. A la déconnexion du client, l'instance est libérée. Cela vous permet de conserver des informations distinctes qui peuvent être utilisées à tout moment durant la session.
Regroupement des modules de données (COM)
Si vous créez un module de données transactionnel qui sera installé sur COM+, vous pouvez utiliser le gestionnaire de composants COM+ pour installer le serveur d’applications comme un objet regroupé.
Même si vous n'utilisez pas un module de données transactionnel, vous pouvez exploiter les avantages du regroupement d'objets si la connexion est constituée en utilisant TWebConnection. Avec ce second type de regroupement d'objets, vous limitez le nombre d'instances créées de votre module de données. Cela limite le nombre de connexions de bases de données à maintenir ainsi que d'autres ressources utilisées par le module de données.
Lorsque l'application serveur Web reçoit les demandes des clients (qui transmettent les appels à votre module de données distant), elle les transmet au premier module de données distant disponible du regroupement. S'il n'y a pas de module de données distant disponible, elle en crée un nouveau (jusqu'au nombre maximal que vous avez spécifié). C'est une solution intermédiaire entre le routage de tous les clients via une seule instance du module de données distant (qui peut créer un goulet d'étranglement) et la création d'une instance séparée pour chaque connexion client (qui gaspille de nombreuses ressources).
Si une instance de module de données distant du groupe ne reçoit pas de demande client pendant un moment, elle est automatiquement libérée. Cela empêche le groupe de monopoliser les ressources inutilement.
Pour configurer le regroupement d'objets avec une connexion Web (HTTP), votre module de données distant doit redéfinir la méthode UpdateRegistry. Dans la méthode redéfinie, appelez RegisterPooled quand le module de données distant est enregistré et UnregisterPooled quand il est désenregisté.
Quand vous utilisez une méthode de regroupement d’objets, votre module de données distant doit être sans état. En effet, une seule instance peut éventuellement gérer des requêtes de plusieurs clients. Si elle dépend d’informations persistantes d’état, des clients peuvent interférer avec d’autres. Pour savoir comment vérifier que votre module de données distant est sans état, voir Gestion des informations d'état dans les modules de données exposés.