Je veux savoir quel est le meilleur moyen d'arriver au niveau d'isolation de la transaction? This is a good link des niveaux d'ISOLATION disponibles.Niveaux ISOLATION dans la transaction
Blockquote Ce sera bien si quelqu'un peut expliquer les différents niveaux d'isolement d'une transaction
Mise à jour: explication décantées et corrigée.
Les niveaux d'isolement indiquent simplement quelle partie de votre transaction est affectée par d'autres transactions simultanées. Plus le niveau d'isolation est élevé, moins il est affecté.
L'effort se manifestera par la charge du processeur, la charge de la mémoire et peut-être la latence de validation. En outre, les conflits d'écriture peuvent être plus probables dans les niveaux d'isolation supérieurs, ce qui peut signifier que vous devez annuler votre transaction et réessayer le tout. (Cela affecte uniquement les transactions qui effectuent des mises à jour ou des insertions, et non les transactions qui effectuent uniquement des sélections.)
En général, la règle de base consiste à utiliser le niveau le plus bas qui donne à votre application la cohérence dont elle a besoin.
L'isolation de transaction partielle fournie par le mode Read Committed est adéquate pour de nombreuses applications, et ce mode est rapide et simple à utiliser; Cependant, ce n'est pas suffisant pour tous les cas. Les applications qui effectuent des requêtes complexes et des mises à jour peuvent nécessiter une vue plus rigoureusement cohérente de la base de données que le mode Read Committed.
Le mode sérialisable fournit une garantie rigoureuse que chaque transaction voit une vue entièrement cohérente de la base de données. Cependant, l'application doit être prête à réessayer des transactions lorsque des mises à jour simultanées rendent impossible le maintien de l'illusion de l'exécution en série. Comme le coût de la reprise des transactions complexes peut être important, le mode sérialisable est recommandé uniquement lorsque la mise à jour des transactions contient une logique suffisamment complexe pour donner des réponses erronées en mode Lecture validée. Le plus souvent, le mode sérialisable est nécessaire lorsqu'une transaction exécute plusieurs commandes successives qui doivent afficher des vues identiques de la base de données.
(http://www.postgresql.org/docs/8.4/interactive/transaction-iso.html est très agréable.)
Désolé, mais le 1er para est faux. Le niveau d'isolation contrôle ce que la transaction en cours va voir des autres transactions, et combien de verrous la transaction en cours va créer. Cela n'affecte pas ce qu'une autre transaction voit - c'est le niveau d'isolation de cette autre transaction qui contrôle ce qu'elle voit. –
Il est probablement plus correct que l'union de votre niveau d'isolement avec d'autres niveaux d'isolement le décide. – Christopher
Ceci est un ancien article, mais j'ai une sous-question connexe ... http://stackoverflow.com/questions/9519610/transaction-isolation-level-massive-number-of-writes – Darwly
Si vous n'êtes pas sûr des différences dans les niveaux d'isolement, puis coller à la valeur par défaut. Changer le niveau peut avoir des effets secondaires particuliers. 99% des applications sont bien avec la valeur par défaut.
La valeur par défaut varie d'un pilote JDBC à l'autre, bien que certains frameworks tels que JPA puissent l'appliquer, je ne peux pas m'en souvenir. La valeur par défaut la plus courante est read_committed, car elle offre le meilleur équilibre général entre la sécurité transactionnelle et la concurrence. Si vous choisissez un niveau d'isolation différent, vous sacrifiez la sécurité ou la concurrence, et vous devez être conscient de la compromission.
Que diable est la question ?!
Les niveaux d'isolement définissent le type de verrouillage et la granularité de verrouillage utilisés par le SGBD. Le verrouillage est essentiel dans le contexte des SGBD, car les transactions sont exécutées simultanément, potentiellement par de nombreux utilisateurs. Une isolation des transactions plus élevée, telle que SERIALIZABLE, est plus sûre: vous pouvez potentiellement éliminer les lectures incorrectes et les mises à jour fantômes, mais imposer une pénalité car les transactions sérialisées limitent la concurrence et empêchent donc l'évolutivité.
Que faire?Architecte l'application de telle sorte que la logique limite la possibilité de «mauvaises données» en utilisant judicieusement des transactions sérialisées lorsqu'elles sont absolument nécessaires, mais pas de telle sorte que la simultanéité soit inutilement entravée.
Que pouvons-nous ajouter à ce que l'article dit déjà? – skaffman