id
nom
prenom
ville
email
1 Dupont
Jean
Houtsiplou jean.dupont@email.com
12 Broussaille Virginie Houtsiplou vibrousaille@email.com
La sélection sur Client se fait sans problème.
Session 2 :
Code : SQL
SELECT *
FROM Adoption
WHERE client_id = 4;
Par contre, la sélection sur Adoption ne passe pas. La session se bloque, jusqu'à ce que la session 1 déverrouille les tables avec
UNLOCK TABLES.
2. Modification sur des tables verrouillées à partir d'une autre session.
Reverrouillez les tables avec la session 1 :
Code : SQL
LOCK TABLES Client READ,
-- Verrou de lecture sur Client
Adoption WRITE;
-- Verrou d'écriture sur Adoption
Session 2 :
Code : SQL
UPDATE Client
SET pays = 'Suisse'
WHERE id = 5;
La modification sur Client, contrairement à la sélection, est bloquée jusqu'au déverrouillage. Déverrouillez puis verrouillez à
nouveau avec la session 1.
Session 2:
Code : SQL
UPDATE Adoption
SET paye = 1
WHERE client_id = 3;
Bien entendu, la modification sur la table Adoption attend également que les verrous soient relâchés par la session 1.
En ce qui concerne la pose de verrous de table par les autres sessions, faites vos propres tests, mais simplement : si une session
peut lire les données d'une table, elle peut également poser un verrou de lecture. Si une session peut modifier les données d'une
table, elle peut également poser un verrou d'écriture.
Interaction avec les transactions
Si l'on utilise des tables MyISAM, il n'y a évidemment aucune précaution particulière à prendre par rapport aux transactions
lorsqu'on utilise des verrous de table (les tables MyISAM étant non-transactionnelles). Par contre, si on utilise des tables
InnoDB, il convient d'être prudent. En effet :
START TRANSACTION ôte les verrous de table ;
Partie 5 : Sécuriser et automatiser ses actions
241/414
www.openclassrooms.com