Comme le dit brb tea, cela dépend de l'implémentation de la base de données et de l'algorithme qu'ils utilisent: MVCC ou Two Phase Locking.
CUBRID (SGBDR open source) explique l'idée de ces deux algorithmes:
- Verrouillage biphasé (2PL)
Le premier est lorsque la transaction T2 tente de modifier l'enregistrement A, elle sait que la transaction T1 a déjà changé l'enregistrement A et attend que la transaction T1 soit terminée car la transaction T2 ne peut pas savoir si la transaction T1 sera validée ou roulée arrière. Cette méthode est appelée verrouillage biphasé (2PL).
- Contrôle d'accès concurrentiel multi-version (MVCC)
L'autre est de permettre à chacune d'elles, transactions T1 et T2, d'avoir sa propre version modifiée. Même lorsque la transaction T1 a changé l'enregistrement A de 1 à 2, la transaction T1 laisse la valeur d'origine 1 telle quelle et écrit que la version de transaction T1 de l'enregistrement A est 2. Ensuite, la transaction T2 suivante modifie l'enregistrement A de 1 à 3, pas de 2 à 4, et écrit que la version de transaction T2 de l'enregistrement A est 3.
Lorsque la transaction T1 est annulée, peu importe si le 2, la version de transaction T1, n'est pas appliqué à l'enregistrement A. Après cela, si la transaction T2 est validée, la version 3, la version de transaction T2, sera appliquée à l'enregistrement A. Si la transaction T1 est validée avant la transaction T2, l'enregistrement A passe à 2, puis à 3 au moment de la validation de la transaction T2. L'état final de la base de données est identique à l'état d'exécution de chaque transaction indépendamment, sans aucun impact sur les autres transactions. Par conséquent, il satisfait la propriété ACID. Cette méthode est appelée contrôle d'accès concurrentiel multi-version (MVCC).
Le MVCC permet des modifications simultanées au prix d'une surcharge accrue en mémoire (car il doit maintenir différentes versions des mêmes données) et en calcul (au niveau REPETEABLE_READ, vous ne pouvez pas perdre les mises à jour, il doit donc vérifier les versions des données, comme Hiberate fait avec Optimistick Locking ).
En 2PL niveaux d'isolement contrôlent les éléments suivants :
Indique si les verrous sont pris lors de la lecture des données et quel type de verrou est demandé.
Combien de temps les verrous de lecture sont maintenus.
Si une opération de lecture référençant des lignes modifiées par une autre transaction:
Bloquer jusqu'à ce que le verrou exclusif sur la ligne soit libéré.
Récupérez la version validée de la ligne qui existait au moment du démarrage de l'instruction ou de la transaction.
Lisez la modification de données non validée.
Le choix d'un niveau d'isolement des transactions n'affecte pas les verrous acquis pour protéger les modifications des données. Une transaction obtient toujours un verrou exclusif sur toutes les données qu'elle modifie et conserve ce verrou jusqu'à ce que la transaction se termine, quel que soit le niveau d'isolement défini pour cette transaction. Pour les opérations de lecture, les niveaux d'isolement des transactions définissent principalement le niveau de protection contre les effets des modifications apportées par d'autres transactions.
Un niveau d'isolation inférieur augmente la capacité de nombreux utilisateurs à accéder aux données en même temps, mais augmente le nombre d'effets de concurrence , tels que des lectures incorrectes ou des mises à jour perdues, que les utilisateurs peuvent rencontrer.
Exemples concrets de la relation entre verrous et niveaux d'isolement dans SQL Server (utilisez 2PL sauf sur READ_COMMITED avec READ_COMMITTED_SNAPSHOT = ON)
READ_UNCOMMITED: n'émettez pas de verrous partagés pour empêcher d'autres transactions de modifier les données lues par la transaction en cours. Les transactions READ UNCOMMITTED ne sont pas non plus bloquées par des verrous exclusifs qui empêcheraient la transaction actuelle de lire les lignes qui ont été modifiées mais non validées par d'autres transactions. [...]
READ_COMMITED:
- Si READ_COMMITTED_SNAPSHOT est défini sur OFF (valeur par défaut): utilise des verrous partagés pour empêcher d'autres transactions de modifier les lignes pendant que la transaction en cours exécute une opération de lecture. Les verrous partagés empêchent également l'instruction de lire les lignes modifiées par d'autres transactions jusqu'à ce que l'autre transaction soit terminée. [...] Les verrous de ligne sont libérés avant que la ligne suivante ne soit traitée. [...]
- Si READ_COMMITTED_SNAPSHOT est défini sur ON, le moteur de base de données utilise la gestion des versions de ligne pour présenter chaque instruction avec un instantané cohérent sur le plan transactionnel des données telles qu'elles existaient au début de l'instruction. Les verrous ne sont pas utilisés pour protéger les données des mises à jour par d'autres transactions.
REPETEABLE_READ: des verrous partagés sont placés sur toutes les données lues par chaque instruction de la transaction et sont conservés jusqu'à la fin de la transaction.
SERIALIZABLE: les verrous de plage sont placés dans la plage de valeurs de clé qui correspondent aux conditions de recherche de chaque instruction exécutée dans une transaction. [...] Les verrous de plage sont maintenus jusqu'à ce que la transaction se termine.