Optimisation à l'aide de la validation à phase unique et de la notification de phase unique pouvant être promue

Cette rubrique décrit les mécanismes fournis par l’infrastructure System.Transactions pour optimiser les performances.

Inscription à phase unique pouvant être promue (PSPE)

L’infrastructure System.Transactions administre une transaction à l’intérieur d’un domaine d’application unique qui implique au maximum une ressource durable unique ou plusieurs ressources volatiles. Étant donné que l’infrastructure System.Transactions utilise uniquement des appels de domaine intra-application, elle génère le meilleur débit et les performances.

Toutefois, si la transaction est fournie à un autre objet d’un autre domaine d’application (y compris entre les limites du processus et de l’ordinateur) sur le même ordinateur, ou si vous deviez inscrire un autre gestionnaire de ressources durable, l’infrastructure System.Transactions augmente automatiquement la transaction à gérer par le MSDTC. Une transaction gérée par MSDTC n’est pas aussi performante qu’une transaction gérée par l’infrastructure System.Transactions .

Pour optimiser les performances, l’infrastructure System.Transactions fournit l’enregistrement promotable à phase unique (PSPE) qui permet à une ressource unique, durable et distante, située dans un autre domaine d’application, processus ou machine, de participer dans une System.Transactions transaction sans provoquer son passage à une transaction MSDTC. Ce gestionnaire de ressources (RM) peut héberger et « posséder » une transaction qui peut ultérieurement être escaladée à une transaction distribuée (ou transaction MSDTC) si nécessaire. Cela réduit le risque d’utilisation du MSDTC.

Ce gestionnaire de ressources spécifique a généralement ses propres transactions internes non distribuées et doit prendre en charge la conversion de ces transactions en transactions distribuées au moment de l’exécution. Par exemple, SQL Server 2005 est un gestionnaire de ressources de ce type. Dans ce cas, l’infrastructure System.Transactions joue un rôle de gestion passif en surveillant simplement la transaction pour déterminer la nécessité d'une escalade. Pour prendre en charge l’interaction entre l’infrastructure System.Transactions et le gestionnaire de ressources, celle-ci doit implémenter l’interface IPromotableSinglePhaseNotification.

La méthode EnlistPromotableSinglePhase permet d'inscrire une ressource durable unique qui peut être remontée ultérieurement. Cette méthode garantit que l'engagement peut être intensifié en fonction des besoins. Si l’inscription réussit, le RM crée sa transaction interne et l’associe à la transaction System.Transactions. Si l’inscription PSPE échoue, le RM doit plutôt s’inscrire en utilisant la méthode EnlistDurable. Les échecs d’inscription dans PSPE peuvent se produire lorsque la transaction est déjà une transaction distribuée, ou lorsqu’un autre RM a déjà effectué une inscription PSPE

Une fois inscrits, les appels par les clients pour valider ou abandonner la System.Transactions transaction sont convertis en appels sur Resource Manager en appelant la SinglePhaseCommit méthode, ou respectivement Rollback .

Si la System.Transactions transaction n’a jamais besoin d’escalade, lorsque la transaction est validée, rm reçoit une SinglePhaseCommit notification. Il peut ensuite valider la transaction interne qui a été initialement créée.

Si la transaction System.Transactions nécessite d'être remontée (pour prendre en charge plusieurs gestionnaires de ressources par exemple), System.Transactions en informe le gestionnaire de ressources en appelant la méthode Promote via l'interface ITransactionPromoter, à partir de laquelle l'interface IPromotableSinglePhaseNotification est dérivée. Le gestionnaire de ressources convertit ensuite la transaction en interne à partir d’une transaction locale (qui ne nécessite pas de journalisation) en objet de transaction capable de participer à une transaction DTC et l’associe au travail déjà effectué. Lorsque la transaction est demandée à valider, le gestionnaire de transactions envoie toujours la SinglePhaseCommit notification au gestionnaire de ressources, qui valide la transaction distribuée qu’elle a créée lors de l’escalade.

Pour plus d’informations sur l’escalade de gestion, consultez Escalade de la gestion des transactions.

Scénario d’escalade de la gestion des transactions

Le scénario suivant illustre une escalade vers une transaction distribuée à l’aide de l’espace de noms System.Data comme « proxy » pour le gestionnaire de ressources. Ce scénario suppose qu’il existe déjà une System.Data connexion à la base de données, CN1, impliquée dans la transaction, et que l’application souhaite impliquer une autre System.Data connexion, CN2. La transaction doit être remontée vers le DTC, en tant que transaction à validation en deux phases entièrement distribuée.

Dans ce scénario,

1. CN1 appelle la EnlistPromotableSinglePhase méthode pour s’inscrire dans la transaction. La transaction restant locale et aucune autre inscription ne pouvant être promue pour la transaction, l'appel EnlistPromotableSinglePhase aboutit.

2. Lorsque CN2, la seconde connexion, appelle EnlistPromotableSinglePhase, l'appel échoue car une autre inscription pouvant être promue est impliquée. En raison de cela, CN2 doit obtenir une transaction DTC pour le transmettre à SQL. Pour ce faire, il utilise l’une des méthodes fournies par la TransactionInterop classe pour produire un format de la transaction qui peut être donné à SQL.

3. System.Transactions appelle la Promote méthode sur l’interface ITransactionPromoter implémentée par CN1.

4. À ce stade, CN1 augmente la transaction, en utilisant un mécanisme spécifique à SQL 2005 et System.Data.

5. La valeur de retour de la Promote méthode est un tableau d’octets qui contient un jeton de propagation pour la transaction. System.Transactions utilise ce jeton de propagation pour créer une transaction DTC qu’elle peut incorporer dans la transaction locale.

6. À ce stade, CN2 peut utiliser les données reçues de l’appel de l’une des méthodes en transmettant TransactionInterop la transaction à SQL.

7. Les deux connexions sont désormais inscrites à une transaction distribuée DTC.

Optimisation de la validation en une phase

Le protocole de validation à phase unique est plus efficace au moment de l’exécution, car toutes les mises à jour sont effectuées sans coordination explicite. Pour tirer parti de cette optimisation, vous devez implémenter un gestionnaire de ressources à l'aide de l'interface ISinglePhaseNotification pour la ressource et vous inscrire dans une transaction à l'aide de la méthode EnlistDurable ou EnlistVolatile. Plus précisément, le paramètre EnlistmentOptions doit être égal à None pour garantir qu'une validation en une seule phase soit effectuée.

Étant donné que l’interface ISinglePhaseNotification dérive de l’interface IEnlistmentNotification , si votre RM n’est pas éligible à la validation à phase unique, elle peut toujours recevoir les notifications de validation en deux phases. Si votre RM reçoit une notification SinglePhaseCommit du TM, il doit essayer d'effectuer le travail nécessaire pour qu'elle soit validée et informer le gestionnaire de transactions si la transaction doit être validée ou annulée en appelant les méthodes Committed, Aborted ou InDoubt sur le paramètre SinglePhaseEnlistment. À ce stade, une réponse de la Done pour l'inscription implique la sémantique ReadOnly. Par conséquent, vous ne devez pas répondre Done en plus des autres méthodes.

S’il n’existe qu’une seule inscription volatile et qu’aucune inscription durable n’est inscrite, l’inscription volatile reçoit une notification SPC. S’il existe des inscriptions volatiles et qu’il n’y a qu’une seule inscription durable, les inscriptions volatiles reçoivent 2PC. Une fois terminée, l'inscription durable reçoit la notification SPC.

Voir aussi

• Inscription de ressources comme participants à une transaction
• Validation d’une transaction en une phase unique et en plusieurs phases