Utilisation de modules de données transactionnels
Remonter à Structure du serveur d'applications
Vous pouvez écrire un serveur d'applications tirant profit des services spécifiques pour les applications distribuées proposées par COM+ (sous Windows 2000 ou plus) ou MTS (avant Windows 2000). Pour ce faire, créez un module de données transactionnel au lieu d'un simple module de données distant.
Lors de l'écriture d'un module de données transactionnel, une application peut exploiter des services spécifiques :
- Sécurité. COM+ (ou MTS) offre au serveur d'applications une sécurité par rôle. Des rôles sont attribués aux clients pour déterminer comment ils peuvent accéder à l'interface du module de données MTS. Le module de données MTS implémente la méthode IsCallerInRole qui vous permet de déterminer le rôle du client connecté et d'autoriser un accès conditionnel à certaines fonctionnalités en fonction du rôle.
- Regroupement des handles de bases de données. Les modules de données transactionnels regroupent automatiquement les connexions de bases de données si vous utilisez ADO ou (si vous utilisez MTS en activant l'option MTS POOLING) le dbExpress. De sorte que, lorsqu'un client n'utilise plus une connexion de base de données, un autre client la réutilise. Ceci allège le trafic réseau car votre niveau intermédiaire n'a pas besoin de se déconnecter du serveur de bases de données distant et de s'y reconnecter. Lorsque les handles de bases de données sont regroupés, votre composant connexion de base de données doit affecter à sa propriété KeepConnection la valeur False, pour que votre application optimise le partage des connexions. .
- Transactions. Lorsque vous utilisez un module de données transactionnel, vous pouvez proposer une gestion améliorée des transactions ne se limitant pas à une seule connexion de base de données. Des modules de données transactionnels peuvent participer à des transactions recouvrant plusieurs bases de données ou contenir des fonctions qui n'impliquent aucune base de données. Pour davantage d'informations sur la gestion des transactions proposée par les objets transactionnels, voir Gestion des transactions dans les applications multiniveaux.
- Activation "juste à temps" et désactivation "dès que possible". Vous pouvez écrire votre serveur de sorte que les instances du module de données distant soient activées et désactivées en fonction des besoins. Lorsque vous utilisez l'activation "juste à temps" et la désactivation "dès que possible", votre module de données distant est instancié uniquement lorsqu'il est requis pour traiter des requêtes client. Cela lui évite de mobiliser des ressources inutilisées comme les handles de bases de données.
L'utilisation de l'activation "juste à temps" et de la désactivation "dès que possible" offre un juste milieux entre le routage de tous les clients par le biais d'une seule instance du module de données distant et la création d'une instance pour chaque connexion client. Avec une seule instance du module de données distant, le serveur d'applications doit traiter tous les appels de bases de données par le biais d'une seule connexion de base de données. Cela aboutit à un goulet d'étranglement et peut pénaliser les performances s'il y a trop de clients. Avec plusieurs instances du module de données distant, chaque instance peut gérer une connexion de base de données, ce qui évite de sérialiser les accès aux bases de données. Toutefois, cela monopolise les ressources car les autres clients ne peuvent pas utiliser la connexion à la base de données tant qu'elle est associée au module de données distant d'un client.
Pour tirer parti des transactions, de l'activation "juste à temps" et de la désactivation "dès que possible", les instances du module de données distant doivent être sans état. Cela signifie que vous devez fournir plus de support lorsque votre client utilise des informations d'état. Par exemple, le client doit passer les informations sur l'enregistrement en cours lors des lectures incrémentales. Pour plus de renseignements sur les informations d'état et les modules de données distants dans les applications multiniveaux, voir Gestion des informations d'état dans les modules de données distants.
Par défaut, tous les appels à un module de données transactionnel générés automatiquement sont transactionnels (ils supposent qu'à la fin de l'appel le module de données peut être désactivé et que toutes les transactions en cours éventuelles peuvent être validées (commit) ou annulées (rollback). Vous pouvez écrire un module de données transactionnel dépendant d'informations d'état persistantes en initialisant à False la propriété AutoComplete, mais il ne supportera pas les transactions, ni l'activation "juste à temps", ni la désactivation "dès que possible" à moins d'utiliser une interface personnalisée.
Avertissement : Les serveurs d'applications utilisant des modules de données transactionnels ne doivent pas ouvrir de connexions de bases de données avant l'activation du module de données. Pendant le développement de votre application, assurez-vous que tous les ensembles de données sont inactifs et que la base de données n'est pas connectée avant l'exécution de votre application. Dans l'application elle-même, vous devez ajouter du code pour ouvrir les connexions de bases de données lors de l'activation du module de données et pour les fermer lors de sa désactivation.