Implémentation d'une transaction implicite à l'aide de l'étendue de transaction

Article
05/10/2023

La classe TransactionScope offre un moyen simple pour indiquer qu'un bloc de code participe à une transaction, sans avoir à intervenir sur la transaction même. Une étendue de transaction peut sélectionner et gérer automatiquement la transaction ambiante. En raison de sa facilité d'utilisation et de son efficacité, il est recommandé d'utiliser la classe TransactionScope lors du développement d'une application de transaction.

De plus, il n'est pas nécessaire d'inscrire explicitement des ressources avec la transaction. Tout gestionnaire de ressources System.Transactions (tel que SQL Server 2005) peut détecter l'existence d'une transaction ambiante créée par l'étendue et l'inscrire automatiquement.

Création d'une étendue de transaction

L'exemple suivant illustre une utilisation simple de la classe TransactionScope.

// This function takes arguments for 2 connection strings and commands to create a transaction
// involving two SQL Servers. It returns a value > 0 if the transaction is committed, 0 if the
// transaction is rolled back. To test this code, you can connect to two different databases
// on the same server by altering the connection string, or to another 3rd party RDBMS by
// altering the code in the connection2 code block.
static public int CreateTransactionScope(
    string connectString1, string connectString2,
    string commandText1, string commandText2)
{
    // Initialize the return value to zero and create a StringWriter to display results.
    int returnValue = 0;
    System.IO.StringWriter writer = new System.IO.StringWriter();

    try
    {
        // Create the TransactionScope to execute the commands, guaranteeing
        // that both commands can commit or roll back as a single unit of work.
        using (TransactionScope scope = new TransactionScope())
        {
            using (SqlConnection connection1 = new SqlConnection(connectString1))
            {
                // Opening the connection automatically enlists it in the
                // TransactionScope as a lightweight transaction.
                connection1.Open();

                // Create the SqlCommand object and execute the first command.
                SqlCommand command1 = new SqlCommand(commandText1, connection1);
                returnValue = command1.ExecuteNonQuery();
                writer.WriteLine("Rows to be affected by command1: {0}", returnValue);

                // If you get here, this means that command1 succeeded. By nesting
                // the using block for connection2 inside that of connection1, you
                // conserve server and network resources as connection2 is opened
                // only when there is a chance that the transaction can commit.
                using (SqlConnection connection2 = new SqlConnection(connectString2))
                {
                    // The transaction is escalated to a full distributed
                    // transaction when connection2 is opened.
                    connection2.Open();

                    // Execute the second command in the second database.
                    returnValue = 0;
                    SqlCommand command2 = new SqlCommand(commandText2, connection2);
                    returnValue = command2.ExecuteNonQuery();
                    writer.WriteLine("Rows to be affected by command2: {0}", returnValue);
                }
            }

            // The Complete method commits the transaction. If an exception has been thrown,
            // Complete is not  called and the transaction is rolled back.
            scope.Complete();
        }
    }
    catch (TransactionAbortedException ex)
    {
        writer.WriteLine("TransactionAbortedException Message: {0}", ex.Message);
    }

    // Display messages.
    Console.WriteLine(writer.ToString());

    return returnValue;
}

'  This function takes arguments for 2 connection strings and commands to create a transaction
'  involving two SQL Servers. It returns a value > 0 if the transaction is committed, 0 if the
'  transaction is rolled back. To test this code, you can connect to two different databases
'  on the same server by altering the connection string, or to another 3rd party RDBMS
'  by altering the code in the connection2 code block.
Public Function CreateTransactionScope( _
  ByVal connectString1 As String, ByVal connectString2 As String, _
  ByVal commandText1 As String, ByVal commandText2 As String) As Integer

    ' Initialize the return value to zero and create a StringWriter to display results.
    Dim returnValue As Integer = 0
    Dim writer As System.IO.StringWriter = New System.IO.StringWriter

    Try
        ' Create the TransactionScope to execute the commands, guaranteeing
        '  that both commands can commit or roll back as a single unit of work.
        Using scope As New TransactionScope()
            Using connection1 As New SqlConnection(connectString1)
                ' Opening the connection automatically enlists it in the
                ' TransactionScope as a lightweight transaction.
                connection1.Open()

                ' Create the SqlCommand object and execute the first command.
                Dim command1 As SqlCommand = New SqlCommand(commandText1, connection1)
                returnValue = command1.ExecuteNonQuery()
                writer.WriteLine("Rows to be affected by command1: {0}", returnValue)

                ' If you get here, this means that command1 succeeded. By nesting
                ' the using block for connection2 inside that of connection1, you
                ' conserve server and network resources as connection2 is opened
                ' only when there is a chance that the transaction can commit.
                Using connection2 As New SqlConnection(connectString2)
                    ' The transaction is escalated to a full distributed
                    ' transaction when connection2 is opened.
                    connection2.Open()

                    ' Execute the second command in the second database.
                    returnValue = 0
                    Dim command2 As SqlCommand = New SqlCommand(commandText2, connection2)
                    returnValue = command2.ExecuteNonQuery()
                    writer.WriteLine("Rows to be affected by command2: {0}", returnValue)
                End Using
            End Using

            ' The Complete method commits the transaction. If an exception has been thrown,
            ' Complete is called and the transaction is rolled back.
            scope.Complete()
        End Using
    Catch ex As TransactionAbortedException
        writer.WriteLine("TransactionAbortedException Message: {0}", ex.Message)
    End Try

    ' Display messages.
    Console.WriteLine(writer.ToString())

    Return returnValue
End Function

L'étendue de transaction démarre après la création d'un nouvel objet TransactionScope. Comme le montre l’exemple de code, il est recommandé de créer des étendues en utilisant une instruction using. L’instruction using est disponible dans C# et Visual Basic, et fonctionne comme un bloc try...finally pour garantir que l’étendue est supprimée correctement.

Lorsque vous instanciez TransactionScope, le gestionnaire de transactions détermine la transaction à laquelle participer. Une fois déterminée, la portée participe toujours à cette transaction. Cette décision est basée sur deux facteurs : la présence d’une transaction ambiante et la valeur du paramètre TransactionScopeOption dans le constructeur. La transaction ambiante est la transaction dans laquelle s'exécute votre code. Vous pouvez obtenir une référence à la transaction ambiante en appelant la propriété Transaction.Current statique de la classe Transaction. Pour plus d’informations sur l’utilisation de ce paramètre, consultez la section Gestion du flux de transaction en utilisant TransactionScopeOption de cette rubrique.

Fin d'une étendue de transaction

Une fois que votre application a effectué toutes les tâches nécessaires au cours d'une transaction, appelez la méthode TransactionScope.Complete (une seule fois) pour informer le gestionnaire de transactions que la transaction peut être validée. C’est une très bonne pratique que de placer l’appel à Complete comme dernière instruction du bloc using.

Ne pas appeler cette méthode se traduit par l’abandon de la transaction, car le gestionnaire de transactions l’interprète comme une défaillance du système, ou équivaut à une exception levée dans l’étendue de transaction. Toutefois, l'appel à cette méthode ne garantit pas la validation de la transaction. Il s’agit simplement d’un moyen d’informer le gestionnaire de transactions de votre état. Après avoir appelé la méthode Complete, vous ne pouvez plus accéder à la transaction ambiante via la propriété Current sous peine de lever une exception.

Si l’objet TransactionScope a créé initialement la transaction, le véritable travail de validation de la transaction par le gestionnaire de transactions intervient après la dernière ligne de code du bloc using. S'il n'a pas créé la transaction, la validation se produit chaque fois que Commit est appelé par le propriétaire de l'objet CommittableTransaction. À ce stade, le gestionnaire de transactions appelle les gestionnaires de ressources et les informe de la validation ou de l’annulation, selon que la méthode Complete a été ou non appelée sur l’objet TransactionScope.

L’instruction using garantit que la méthode Dispose de l’objet TransactionScope est appelée même si une exception se produit. La méthode Dispose marque la fin de l'étendue de transaction. Il est possible que les exceptions qui se produisent après l’appel à cette méthode n’affectent pas la transaction. Cette méthode restaure également la transaction ambiante à son état précédent.

Une exception TransactionAbortedException est levée si l'étendue crée la transaction et que cette transaction est abandonnée. Une exception TransactionInDoubtException est levée si le gestionnaire de transactions ne parvient pas à aboutir à une décision de validation. Aucune exception n'est levée si la transaction est validée.

Restauration d’une transaction

Pour restaurer une transaction, n'appelez pas la méthode Complete dans l'étendue de transaction. Par exemple, vous pouvez lever une exception dans l'étendue. La transaction à laquelle il participe est restaurée.

Gestion du flux de transaction à l'aide de TransactionScopeOption

L'étendue de transaction peut être imbriquée en appelant une méthode qui utilise une TransactionScope à partir d'une méthode utilisant sa propre étendue, comme la méthode RootMethod de l'exemple suivant,

void RootMethod()
{
    using(TransactionScope scope = new TransactionScope())
    {
        /* Perform transactional work here */
        SomeMethod();
        scope.Complete();
    }
}

void SomeMethod()
{
    using(TransactionScope scope = new TransactionScope())
    {
        /* Perform transactional work here */
        scope.Complete();
    }
}

L'étendue de transaction supérieure est appelée « étendue racine ».

La classe TransactionScope fournit plusieurs constructeurs surchargés qui acceptent une énumération de type TransactionScopeOption, qui définit le comportement transactionnel de l'étendue.

Un objet TransactionScope dispose de trois options :

Joindre la transaction ambiante ou en créer une nouvelle s'il n'en existe pas.
Constituer une nouvelle étendue racine, c'est-à-dire démarrer une nouvelle transaction et en faire la nouvelle transaction ambiante de sa propre étendue.
Ne participer à aucune transaction. En conséquence, il n'y a pas de transaction ambiante.

Si l'étendue est instanciée avec Required et qu'une transaction ambiante existe, l'étendue joint cette transaction. En revanche, s'il n'y a pas de transaction ambiante, l'étendue en crée une nouvelle et devient l'étendue racine. Il s’agit de la valeur par défaut. Si Required est utilisé, le code de l'étendue n'a pas à se comporter différemment selon qu'il s'agit de la racine ou seulement de la jonction de la transaction ambiante. Il fonctionne de la même façon dans les deux cas.

Si l'étendue est instanciée avec RequiresNew, il s'agit toujours de l'étendue racine. Une nouvelle transaction démarre et devient la nouvelle transaction ambiante de l'étendue.

Si la portée est instanciée avec Suppress, elle ne prend jamais part à une transaction, qu'une transaction ambiante existe ou non. Une étendue instanciée avec cette valeur a toujours null pour sa transaction ambiante.

Ces options sont répertoriées dans le tableau suivant.

TransactionScopeOption	Transaction ambiante	L'étendue participe à
Obligatoire	Non	Nouvelle transaction (future racine)
Nouveau requis	Non	Nouvelle transaction (future racine)
Suppress	Non	Aucune transaction
Obligatoire	Oui	Transaction ambiante
Nouveau requis	Oui	Nouvelle transaction (future racine)
Suppress	Oui	Aucune transaction

Lorsqu'un objet TransactionScope joint une transaction ambiante existante, la suppression de l'objet d'étendue peut ne pas entraîner l'arrêt de la transaction, à moins que l'étendue abandonne la transaction. Si la transaction ambiante a été créée par une étendue racine, seulement lorsque l'étendue racine est supprimée, Commit est appelé sur la transaction. Si la transaction a été créée manuellement, elle se termine lors de son abandon ou de sa validation par son créateur.

L'exemple suivant montre un objet TransactionScope qui crée trois objets d'étendue imbriqués, chacun étant instancié avec une valeur TransactionScopeOption différente.

using(TransactionScope scope1 = new TransactionScope())
//Default is Required
{
    using(TransactionScope scope2 = new TransactionScope(TransactionScopeOption.Required))
    {
        //...
    }

    using(TransactionScope scope3 = new TransactionScope(TransactionScopeOption.RequiresNew))
    {
        //...  
    }
  
    using(TransactionScope scope4 = new TransactionScope(TransactionScopeOption.Suppress))
    {
        //...  
    }
}

Cet exemple montre un bloc de code sans transaction ambiante créant une nouvelle étendue (scope1) avec Required. La portée scope1 est une portée racine, car elle crée une transaction (Transaction A) pour en faire la transaction ambiante. Scope1 crée ensuite trois autres objets, chacun avec une valeur TransactionScopeOption différente. Par exemple, scope2 est créée avec Required et puisqu'il s'agit d'une transaction ambiante, elle joint la première transaction créée par scope1. Notez que scope3 est l'étendue racine d'une nouvelle transaction et que scope4 ne dispose pas de transaction ambiante.

Bien que la valeur par défaut, et la plus utilisée, de TransactionScopeOption est Required, chacune des autres valeurs a une fonction unique.

Code non transactionnel à l’intérieur d’une étendue de transaction

Suppress est utile quand vous voulez conserver les opérations effectuées par la section de code et que vous ne voulez pas abandonner la transaction ambiante si les opérations échouent. Pour effectuer des opérations d'enregistrement ou d'audit par exemple, ou pour publier des événements aux abonnés, indépendamment de la validation ou de l'abandon de votre transaction ambiante. Cette valeur vous permet d'avoir une section de code non transactionnelle dans une étendue de transaction, comme illustré dans l'exemple suivant.

using(TransactionScope scope1 = new TransactionScope())
{
    try
    {
        //Start of non-transactional section
        using(TransactionScope scope2 = new
            TransactionScope(TransactionScopeOption.Suppress))  
        {  
            //Do non-transactional work here  
        }  
        //Restores ambient transaction here
   }
   catch {}  
   //Rest of scope1
}

Vote au sein d'une étendue imbriquée

Bien qu’une étendue imbriquée puisse joindre la transaction ambiante de l’étendue racine, l’appel de Complete dans l’étendue imbriquée n’a pas d’effet sur l’étendue racine. La transaction est commitée seulement si toutes les étendues, de l’étendue racine à la dernière étendue imbriquée, votent son commit. Le non-appel de Complete dans une étendue imbriquée affecte l’étendue racine, car la transaction ambiante est immédiatement abandonnée.

Définition du délai d'attente TransactionScope

Certains des constructeurs surchargés de TransactionScope acceptent une valeur de type TimeSpan, utilisée pour contrôler le délai d'attente de la transaction. La valeur zéro indique un délai d'attente infini. Le délai d'attente infini est particulièrement utile pour le débogage, lorsque vous voulez isoler un problème au sein de votre logique métier grâce au code, sans que la transaction que vous déboguez expire lors de la localisation du problème. Utilisez la valeur de délai d'attente infini avec précaution dans tous les autres cas, car elle substitue les dispositifs de protection par des blocages de transaction.

Le délai d'attente TransactionScope peut prendre des valeurs autres que celle par défaut dans deux cas. Le premier cas intervient lors du développement, lorsque vous voulez tester la façon dont votre application gère les transactions abandonnées. En affectant une faible valeur au délai d'attente (tel qu'une milliseconde), vous provoquez l'échec de la transaction et pouvez ainsi obtenir le code de gestion des erreurs. Le second cas pour lequel il est nécessaire de définir une valeur inférieure au délai d'attente par défaut est lorsque vous pensez que l'étendue est à l'origine de conflits de ressources, causant des blocages. Dans ce cas, abandonnez la transaction dès que possible et n'attendez pas l'expiration du délai d'attente par défaut.

Lorsqu'une étendue joint une transaction ambiante avec un délai d'attente plus court que celui de la transaction ambiante, le nouveau délai, plus court, est appliqué à l'objet TransactionScope et l'étendue doit se terminer dans le temps imbriqué spécifié, sans quoi la transaction est automatiquement abandonnée. Si le délai d'attente de l'étendue imbriquée est supérieur à celui de la transaction ambiante, il n'a aucun effet.

Définition du niveau d'isolation TransactionScope

Certains des constructeurs surchargés de TransactionScope acceptent une structure de type TransactionOptions pour spécifier un niveau d'isolation, en plus d'une valeur de délai d'attente. Par défaut, la transaction s'exécute avec un niveau d'isolation de valeur Serializable. On utilise habituellement un niveau d'isolation autre que Serializable pour les systèmes de lecture intensive. Cela requiert une solide compréhension de la théorie sur le traitement des transactions et de la sémantique de la transaction même, des problèmes d'accès concurrentiel ainsi que des conséquences pour la cohérence du système.

De plus, tous les gestionnaires de ressources ne supportent pas l'ensemble des niveaux d'isolation et peuvent choisir de prendre part à la transaction à un niveau supérieur à celui configuré.

Chaque niveau d'isolation, hormis Serializable, est susceptible de résulter de façon incohérente d'autres transactions accédant aux mêmes informations. La différence entre les niveaux d'isolation réside dans l'utilisation des verrous de lecture et d'écriture. Un verrou ne peut être maintenu que lorsque la transaction accède aux données du gestionnaire de ressources ou jusqu'à ce que la transaction soit validée ou abandonnée. Le premier est utilisé pour le débit et le deuxième pour la cohérence. Les deux types de verrou et les deux types d'opération (lecture/écriture) donnent quatre niveaux d'isolation de base. Consultez la rubrique IsolationLevel (éventuellement en anglais) pour plus d'informations.

En cas d'utilisation d'objets TransactionScope imbriqués, toutes les étendues imbriquées doivent être configurées pour utiliser le même niveau d'isolation pour pouvoir joindre la transaction ambiante. Si un objet TransactionScope imbriqué tente de joindre la transaction ambiante avec un niveau d'isolation différent, une exception ArgumentException est levée.

Interopérabilité avec COM+

Lors de la création d'une nouvelle instance TransactionScope, vous pouvez utiliser l'énumération EnterpriseServicesInteropOption dans l'un des constructeurs pour spécifier comment interagir avec COM+. Pour plus d’informations sur cette question, consultez Interopérabilité avec Enterprise Services et les transactions COM+.

Partager via