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

  • Article

Cette rubrique décrit les mécanismes fournis par l'infrastructure System.Transactions pour l'optimisation des performances.

Inscription à phase unique pouvant être promue (PSPE)

L'infrastructure System.Transactions gère une transaction dans un domaine d'application unique qui comprend une seule ressource durable ou plusieurs ressources volatiles. L'infrastructure System.Transactions n'utilise que des appels intra-domaines d'application, elle offre donc le meilleur débit et d'excellentes performances.

Cependant, si la transaction est fournie à l'objet d'un autre domaine d'application (y compris au-delà de limites de processus et d'ordinateurs) du même ordinateur ou si vous tentez d'inscrire un autre gestionnaire de ressources durables, l'infrastructure System.Transactions remonte automatiquement la transaction pour gestion par le MSDTC. Une transaction managée par le MSDTC n'est pas aussi performante qu'une transaction managée par l'infrastructure System.Transactions.

Pour optimiser les performances, l'infrastructure System.Transactions propose la PSPE qui permet à une ressource durable distante, située dans un domaine d'application, processus ou ordinateur différent, de participer à une transaction System.Transactions sans entraîner sa remontée en transaction MSDTC. Cela permet au gestionnaire de ressources d'héberger et de « posséder » une transaction qui peut, si nécessaire, être ensuite remontée vers une transaction distribuée (ou une transaction MSDTC). Cela réduit l'utilisation du MSDTC.

Ce gestionnaire de ressources spécifique dispose généralement de ses propres transactions internes non distribuées et doit prendre en charge leur conversion en transactions distribuées au moment de l’exécution. SQL Server 2005 fait, par exemple, partie de ces gestionnaires de ressources. Dans ce cas, l'infrastructure System.Transactions joue un rôle de gestion passif et se contente de surveiller la transaction pour une remontée éventuelle. Pour prendre en charge l'interaction entre l'infrastructure System.Transactions et le gestionnaire de ressources, ce dernier 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 la remontée possible de l'inscription si besoin. Si l'inscription aboutit, le gestionnaire de ressources crée sa transaction interne et l'associe à la transaction System.Transactions. Si l'inscription PSPE échoue, le gestionnaire de ressources doit s'inscrire à l'aide de la méthode EnlistDurable. Il est impossible de s'inscrire à la PSPE lorsqu'il s'agit déjà d'une transaction distribuée ou lorsqu'un autre gestionnaire de ressources a déjà procédé à une inscription PSPE

Une fois l'inscription effectuée, les appels des clients pour la validation ou l'abandon de la transaction System.Transactions sont convertis en appels vers le gestionnaire de ressources par appel à la méthode SinglePhaseCommit ou Rollback, respectivement.

Si la transaction System.Transactions ne nécessite jamais de remontée, le gestionnaire de ressources reçoit une notification SinglePhaseCommit lors de la validation de la transaction Il peut ensuite valider la transaction interne qui avait é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 (ne nécessitant aucune connexion) en un objet de transaction pouvant participer à une transaction DTC, et l'associe au travail déjà effectué. Lors de la demande de validation de la transaction, le gestionnaire de transactions continue d'envoyer la notification SinglePhaseCommit au gestionnaire de ressources, qui valide la transaction distribuée créée lors de la remontée.

Notes

Les traces TransactionCommitted (générées lors de l’appel d’une validation sur la transaction remontée) comprennent l’ID d’activité de la transaction DTC.

Pour plus d’informations sur la remontée de la gestion, consultez Remontée de la gestion des transactions.

Scénario de remontée de la gestion des transactions

Le scénario suivant présente une remontée vers une transaction distribuée effectuée avec le nom d'espaces System.Data utilisé comme « proxy » pour le gestionnaire de ressources. Ce scénario suppose qu'une connexion System.Data à la base de données (CN1), impliquée dans la transaction, est déjà établie et que l'application veut établir une seconde connexion System.Data, (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 méthode EnlistPromotableSinglePhase pour s'inscrire à 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. CN2 doit donc obtenir une transaction DTC pour la passer à SQL. Pour cela, elle utilise l'une des méthodes fournies par la classe TransactionInterop pour produire une transaction à un format pouvant être envoyé à SQL.

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

  4. CN1 remonte alors la transaction grâce à un mécanisme spécifique à SQL 2005 et System.Data.

  5. La valeur de retour de la méthode Promote est un tableau d'octets qui contient un jeton de propagation de la transaction. System.Transactions utilise ce jeton de propagation pour créer une transaction DTC pouvant être incorporée dans la transaction locale.

  6. CN2 peut alors utiliser les données reçues par appel à l'une des méthodes par TransactionInterop pour passer 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 en une phase est plus efficace au moment de l’exécution car toutes les mises à jour sont effectuées sans coordination explicite. Pour tirer partie de cette optimisation, implémentez un gestionnaire de ressources via l'interface ISinglePhaseNotification pour la ressource et inscrivez-vous à 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 l’exécution de la validation en une phase.

L'interface ISinglePhaseNotification étant dérivée de l'interface IEnlistmentNotification, si votre gestionnaire de ressources ne peut pas prétendre à la validation en une phase, il peut tout de même recevoir les notifications relatives à la validation en deux phases. Si votre gestionnaire de ressources reçoit une notification SinglePhaseCommit du gestionnaire de transactions, il doit tenter d'effectuer le nécessaire pour la validation et informer le gestionnaire de transactions de la validation ou de la restauration de la transaction en appelant la méthode Committed, Aborted ou InDoubt pour le paramètre SinglePhaseEnlistment. À ce stade, une réponse de la Done pour l'inscription implique la sémantique ReadOnly. Par conséquent, ne répondez pas à la Done en plus des autres méthodes.

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

Voir aussi