Lecture répétée vs Optimistic

Question

Quelle est la différence entre le contrôle de concurrence et les niveaux d'isolation des transactions?

Je comprends chacun d'eux clairement, cependant, j'ai quelques problèmes les reliant les uns aux autres. Plus précisément, je vois un certain chevauchement dans leurs fonctions et je ne suis pas sûr quand on devrait utiliser l'un sur l'autre. Ou devrait-on les utiliser ensemble?

En outre, que signifie «verrouillage pessimiste avec lecture répétable»? La lecture non répétable n'implique-t-elle pas déjà que toutes les valeurs à éditer seront verrouillées? Alors pourquoi y a-t-il encore un besoin de verrouillage pessimiste?

Answer 1

Le problème survient car il existe deux modèles de contrôle de simultanéité, qui sont parfois mélangés par des implémentations SQL.

1. serrures, comme dans 2PL (deux) de verrouillage de phase
2. versions, comme dans MVCC (Multiversion Contrôle d'accès simultané)

moyens pessimistes lignes qui sont lues sont verrouillées. Optimiste signifie que les lignes lues ne sont pas verrouillées.

L'implémentation 2PL classique de Repeatable Read est toujours pessimiste. L'implémentation multiversion de Lecture répétable est optimiste. Il ne verrouille pas les lignes qui sont lues pour une instruction SELECT et permet à d'autres transactions de modifier les lignes qui ont été lues dans un SELECT. Ces modifications ne sont pas visibles pour la transaction qui a effectué le SELECT, jusqu'à ce qu'il soit validé.

Answer 2

Contrôle d'accès concurrentiel est un terme général désignant tout mécanisme gérant les problèmes liés aux connexions simultanées.

Les niveaux d'isolement de transaction sont un mécanisme par lequel MySQL implémente le contrôle de concurrence.

Voir Consistent Nonlocking Reads pour la documentation sur la façon dont MySQL implémente REPEATABLE READ sans verrouillage pessimiste:

Une lecture cohérente ne fixe pas de verrous sur les tables auxquelles il accède, et donc d'autres sessions sont libres de modifier ces tables en même Une lecture cohérente est effectuée sur la table. Supposons que vous exécutez le niveau d'isolement par défaut REPEATABLE READ. Lorsque vous émettez une lecture cohérente (c'est-à-dire une instruction ordinaire SELECT), InnoDB attribue à votre transaction un point temporel selon lequel votre requête voit la base de données. Si une autre transaction supprime une ligne et qu'elle est validée après que votre point de temps a été affecté, vous ne voyez pas la ligne comme ayant été supprimée. Les insertions et les mises à jour sont traitées de la même manière.