101 votes

Devrais-je valider ou annuler une transaction de lecture?

J'ai une requête en lecture que j'exécute à l'intérieur d'une transaction de sorte que je peux spécifier le niveau d'isolation. Une fois la requête terminée, que dois-je faire?

  • Valider la transaction
  • Annuler la transaction
  • Ne rien faire (ce qui sera la cause de la transaction à être annulées à la fin de l'utilisation de bloc)

Quelles sont les implications de chaque?

using (IDbConnection connection = ConnectionFactory.CreateConnection())
{
    using (IDbTransaction transaction = connection.BeginTransaction(IsolationLevel.ReadUncommitted))
    {
        using (IDbCommand command = connection.CreateCommand())
        {
            command.Transaction = transaction;
            command.CommandText = "SELECT * FROM SomeTable";
            using (IDataReader reader = command.ExecuteReader())
            {
                // Read the results
            }
        }

        // To commit, or not to commit?
    }
}

EDIT: La question n'est pas si une transaction doit être utilisé ou s'il existe d'autres moyens pour régler le niveau de la transaction. La question est de savoir si cela fait une différence que l'une transaction qui ne permet pas de modifier quoi que ce soit est validée ou annulée. Est-il une différence de performance? Il n'affecte pas les autres connexions? Toutes les autres différences?

53voto

Mark Brackett Points 46824

De vous engager. Période. Il n'y a pas d'autre solution raisonnable. Si vous avez commencé une transaction, vous devez le fermer. Commettre libère tous les verrous que vous pourriez avoir eu, et il est tout aussi sensible avec ReadUncommitted ou Serializable les niveaux d'isolation. En s'appuyant sur l'implicite de la fonction restauration - tout peut-être techniquement équivalent est juste une mauvaise forme.

Si cela n'est pas convaincu que vous, imaginez le gars à côté qui insère une instruction de mise à jour dans le milieu de votre code, et a pour traquer le rollback implicite qui se produit et enlève ses données.

29voto

Graeme Perrow Points 22249

Si vous n'avez rien changé, vous pouvez utiliser un COMMIT ou un ROLLBACK. Les deux verrouillent les verrous de lecture que vous avez acquis et, étant donné que vous n'avez apporté aucune autre modification, ils seront équivalents.

7voto

Neil Barnwell Points 20731

Si vous commencez une transaction, la meilleure pratique consiste toujours à la commettre. Si une exception est levée dans votre bloc d'utilisation (transaction), la transaction sera automatiquement annulée.

2voto

Joel Coehoorn Points 190579

Juste une note, mais vous pouvez aussi écrire ce code comme ceci:

 using (IDbConnection connection = ConnectionFactory.CreateConnection())
using (IDbTransaction transaction = connection.BeginTransaction(IsolationLevel.ReadUncommitted))
using (IDbCommand command = connection.CreateCommand())
{
    command.Transaction = transaction;
    command.CommandText = "SELECT * FROM SomeTable";
    using (IDataReader reader = command.ExecuteReader())
    {
        // Do something useful
    }
    // To commit, or not to commit?
}
 

Et si vous restructurez un peu les choses, vous pourrez peut-être également déplacer le bloc using pour IDataReader.

1voto

Eric Z Beard Points 18473

Si vous mettez le code SQL dans une procédure stockée et ajouter au-dessus de la requête:

set transaction isolation level read uncommitted

ensuite, vous n'avez pas à sauter par tout cerceaux dans le code C#. Réglage du niveau d'isolation de transaction dans une procédure stockée ne cause pas le paramètre s'applique à toutes les utilisations futures de la connexion (qui est quelque chose que vous avez à vous soucier avec d'autres paramètres depuis les connexions sont mis en commun). À la fin de la procédure stockée, il va juste revenir à ce que la connexion a été initialisé avec.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X