Transactions pour un accès DB en lecture seule?

Question

Il semble exister des opinions très divergentes sur l'utilisation de transactions pour lire dans une base de données.

Citation de l'article DeveloperWorks Stratégies de transaction: modèles et aperçu des stratégies :

  

Pourquoi auriez-vous besoin d'une transaction si   vous lisez seulement des données? La réponse   est-ce que vous ne le faites pas. À partir d'un   transaction pour effectuer une lecture seule   opération ajoute à la surcharge de la   traitement de thread et peut causer partagé   lire les verrous sur la base de données (selon   sur quel type de base de données vous utilisez   et quel est le niveau d'isolement   à).

Comme opinion contraire, la citation suivante de la documentation Hibernate est Accès non transactionnel aux données et validation automatique. mode

  

Notre recommandation est de ne pas utiliser le   mode autocommit dans une application, et   appliquer uniquement des transactions en lecture seule   quand il y a une performance évidente   avantage ou lorsque les changements de code futurs   sont hautement improbables. Toujours préférer   transactions ACID régulières à regrouper   vos opérations d'accès aux données,   peu importe si vous lisez ou   écrire des données.

Il existe également un débat similaire sur la liste de diffusion EclipseLink ici. .

Alors, où est la vérité? Les transactions pour lire les meilleures pratiques sont-elles ou non? Si les deux solutions sont viables, quels sont les critères d’utilisation des transactions?

Autant que je sache, cela ne fait de différence que si le niveau d'isolement est supérieur à "Lecture validée". Est-ce correct?

Quelles sont les expériences et les recommandations?

Answer 1

Steven Devijver a donné quelques bonnes raisons de démarrer des transactions même si les opérations ne font que lire la base de données:

• Définir les délais ou les modes de verrouillage
• Définir le niveau d'isolement

Le SQL standard exige que même une requête doit démarrer une nouvelle transaction si aucune transaction n'est en cours. Il y a des SGBD où ce n'est pas ce qui se passe - ceux avec un mode autocommit, par exemple (l'instruction démarre une transaction et la valide immédiatement). Les autres SGBD font des déclarations atomiques (effectivement autocommit) par défaut, mais démarrent une transaction explicite avec une instruction telle que 'BEGIN WORK', annulant l'auto-validation jusqu'à la prochaine COMMIT ou ROLLBACK (IBM Informix Dynamic Server en est une - lorsque la base de données n'est pas en mode MODE ANSI).

Je ne suis pas sûr du conseil de ne jamais revenir en arrière. Cela ne change rien à la transaction en lecture seule et, dans la mesure où cela gêne vos administrateurs de base de données, il est préférable d'éviter ROLLBACK. Mais si votre programme se termine sans COMMIT, le SGBD doit effectuer un ROLLBACK sur votre transaction incomplète - certainement s'il a modifié la base de données et (pour simplifier) ??même si vous n'avez sélectionné que des données.

Dans l’ensemble, si vous souhaitez modifier le comportement par défaut d’une série d’opérations, utilisez une transaction, même si elle est en lecture seule. Si vous êtes satisfait du comportement par défaut, l'utilisation d'une transaction n'est pas cruciale. Si votre code doit être portable entre les SGBD, il est préférable de supposer que vous aurez besoin d’une transaction.

Answer 2

Tout d’abord, cela ressemble à une optimisation prématurée. Comme Steven l'a fait remarquer, la plupart des bases de données rationnelles vont de toute façon vous placer dans une transaction, et tout ce qu'elles font consiste à appeler commit après chaque instruction. Ainsi, de ce point de vue, autocommit pourrait être moins performant puisque chaque instruction doit démarrer une nouvelle transaction. Ou peut être pas. Seul le benchmarking le dira et je parie que cela ne changera rien à votre application.

Une des raisons pour lesquelles vous souhaitez toujours utiliser une transaction est la cohérence de la protection. Si vous commencez à jouer avec la déclaration manuelle d'une transaction uniquement lorsque vous avez "besoin" de alors vous allez oublier à un moment critique. Ou cet ensemble d'opérations supposément en lecture seule ne l'est soudainement pas, soit parce qu'un programmeur ultérieur n'a pas réalisé qu'il était censé l'être, soit parce que votre code appelle une fonction qui a une écriture masquée. Par exemple, je configure mes clients de base de données en ligne de commande pour qu'ils ne se commettent pas automatiquement. Cela signifie que je peux utiliser une requête de suppression avec le doigt de votre doigt et continuer à revenir en arrière.

Il y a le niveau d'isolement, comme indiqué. Cela vous permet de faire plusieurs lectures sans vous inquiéter si un autre processus a écrit entre vos données, ce qui rend votre lecture efficacement atomique. Cela vous évitera de nombreuses heures de débogage d'une situation critique.

Enfin, vous pouvez souvent définir une transaction en lecture seule. Ceci vérifie votre hypothèse et provoquera une erreur si quelque chose essaie d’écrire.

Voici un bel article résumant le tout . Les détails sont spécifiques à Oracle, mais les concepts sont génériques.

Answer 3

Les transactions sont obligatoires pour les opérations en lecture seule si vous souhaitez définir un délai d'expiration spécifique pour les requêtes autres que le délai d'expiration par défaut ou si vous souhaitez modifier le niveau d'isolation.

De plus, chaque base de données (ne connaissant pas les exceptions) lancera une transaction en interne pour chaque requête. En règle générale, on considère qu’il n’est pas fait d’annuler des transactions lorsque cette annulation n’est pas requise.

Les administrateurs de base de données peuvent surveiller l'activité d'annulation et tout comportement d'annulation par défaut les gênera dans ce cas.

Donc, les transactions sont utilisées quand même, que vous les commenciez ou pas. Si vous n'en avez pas besoin, ne les démarrez pas, mais ne procédez jamais à une restauration en lecture seule.