Expert Module de données transactionnel

Remonter à Menu Fichier

Fichier > Nouveau > Autre...

Utilisez l'expert Module de données transactionnel pour créer un module serveur s'exécutant sous MTS ou COM+.

Remarque : Pour ajouter un module de données transactionnel, vous devez ajouter au préalable une bibliothèque ActiveX au projet, localisable sur la page Activex.

Elément	Description
Nom de CoClasse	Spécifiez le nom de l'objet que vous souhaitez implémenter. L'expert génère une interface portant ce nom précédé de la lettre 'I' et une classe d'implémentation avec ce nom précédé de la lettre 'T'.
Description	Entrez une description facultative du module de données que vous créez.
Modèle de thread	Choisissez le modèle de thread pour indiquer comment MTS ou COM+ sérialise les appels à l'interface du module transactionnel. Le modèle de thread choisi détermine la façon dont le module est recensé. Vous devez vous assurer que votre implémentation du module adhère au modèle sélectionné. Les valeurs de modèle de thread sont présentées ci-dessous.
Modèle de transaction	Spécifiez l'attribut de transaction assigné à votre module quand vous le recensez. Les valeurs possibles sont présentées ci-dessous.

La zone de liste Modèle de thread peut prendre les valeurs suivantes :

Modèle	Description
Unique	Votre code ne dispose pas de support de thread. Un seul thread client peut être servi à la fois.
Apartment	Sous COM+, chaque module instancié par un client est accédé par un seul thread à la fois. Vous devez empêcher l'accès de plusieurs threads à la mémoire globale, mais les modules peuvent accéder de manière sécurisée à leur propre données d'instance (propriétés de l'objet et membres). Sous MTS également, tous les appels client utilisent le thread sous lequel le module a été créé.
Les deux	Comme Apartment sauf que les callbacks aux clients sont sérialisés.
Neutre	Plusieurs clients peuvent appeler le module sur différents threads en même temps, mais COM assure qu'il n'y a pas de conflit entre deux appels. Vous devez éviter les conflits de threads impliquant des données globales et toutes les données d'instance accédées par plus d'une méthode. Ce modèle ne doit pas être utilisé avec un module ayant une interface utilisateur. Ce modèle est seulement disponible sous COM+. Sous COM, il est mappé sur le modèle Apartment.

La zone de liste Modèle de transaction peut prendre les valeurs suivantes :

Valeur	Signification
Requiert une transaction	Le module doit s'exécuter dans la portée d'une transaction. Lorsqu'un nouveau module est créé, son contexte de module hérite de la transaction du contexte du client. Si le client n'a pas de contexte de transaction, un nouveau contexte de transaction est généré automatiquement.
Requiert une nouvelle transaction	Le module doit s'exécuter dans sa propre transaction. Lorsqu'un nouveau module est créé, un contexte de nouvelle transaction est également créé automatiquement, que son client ait ou non une transaction. Le module ne s'exécute jamais dans la portée de la transaction de son client. En revanche, le système crée toujours des transactions indépendantes pour les nouveaux objets.
Supporte les transactions	Le module peut s'exécuter dans la portée des transactions de son client. Lorsqu'un nouveau module est créé, son contexte de module hérite de la transaction du contexte du client si elle existe. Sinon, le module n'est pas créé dans la portée d'une transaction.
Ne supporte pas les transactions	Sous MTS, cette option induit un comportement identique à l'option Transaction ignorée sous COM+. Sous COM+, le module ne peut pas s'exécuter dans le contexte d'une transaction. Si le client a une transaction, les tentatives de création du module échoueront.
Ignore les transactions	Le module ne s'exécute pas dans la portée des transactions. Lorsqu'un nouveau module est créé, son contexte de module est créé sans transaction, que son client ait ou non une transaction. Ce modèle n'est pas supporté sous MTS.

Voir aussi

• Utilisation de modules de données transactionnels