salut

Sebastien Grand a écrit :
> 
> Salut,
> je ne connais pas mysql mais sous Oracle, il n'y a aucun problème:
> Lorsqu'une table est lockée (par exemple pour insérer des données), on peut
> toujours faire des select dessus.
> En fait, le lock empêche deux personnes de modifier en même temps la même
> table.Il est donc impossible sur une table lockée d'utiliser les commandes de
> manipulation des données (LMD): UPDATE,INSERT, DELETE. Par contre
> l'interrogation des données (LID) est possible SELECT.
> 
> Par exemple, la personne qui fait un select sur une table lockée ne voit pas
> encore les nouvelles lignes insérer (si la personne qui locke la table effectue
> des insertions), il voit la table dans son état initial avant le lock.Il faut
> que le commit soit effectué pour voir les nouvelles lignes.
> 
> Mais, je ne sais pas si mysql fonctionne de la même manière !
> 
> Quelqu'un connaissant mysql pourra peut-être donner plus d'infos.
> Seb
> 
> >Bonjour,
> 
> >Je voudrais savoir :
> >Si je fais un lock sur une table, et qu'un autre thread essaye de faire un
> >select sur cette table, que se passe-t-il ?
> >1) select attend la liberation du lock (unlock) et execute sa requete
> >ou
> >2) select retourne une erreur
> 
> >Merci !
> 
> --
> >Alain
> 

Extrait du manuel Mysql :

        LOCK TABLES verrouille une table dans le thread courant. UNLOCK
TABLES ouvre tous les verrous posé par le thread courant. Toutes les
tables
        verrouillé par un thread sont automatiquement déverrouillée
quand le thread émet un autre LOCK TABLES, ou à la fin de la connexion
au serveur. 

        Si un thread obtiens le verrou de lecture (READ) sur une table,
le thread (et tous les autres threads) ne peut que lire dans la table.
Si un thread
        obtiens e verrou de lecture (READ) sur une table, le thread qui
a le verrous est le seul à pouvoir lire ou écrire dans la table. 

        Les autres threads attendent (sans limite) que le verrous se
libère. 

        Le verrous d'écriture a une priorité supérieure au verrou de
lecture, afin que les processus de mise à jour puisse se faire dès que
possible. Cela
        signifie que si un thread obtiens un verrou de lecture, et qu'un
autre thread obtiens un verrou d'écriture, alors le thread au verrou de
lecture
        devra attendre la libération du verrou d'écriture. Il est
possible d'utiliser des verrous d'écriture de basse priorité
(LOW_PRIORITY WRITE), mais il
        faut être sur qu'il y aura un moment ou aucun thread ne sera en
train de lire la table. 

        Lors de l'utilisation de la commande LOCK TABLES, il faut
verrouiller toutes les tables qui vont être utilisées. Si il y a des
alias dans une requête,
        il faut aussi avoir les verrous pour les alias! Cette politique
assure que la table ne se verrouille jamais, sans pouvoir être
déverrouillée. 

        Il ne faut jamais verrouiller une table qui va accepter une
insertion reportée (INSERT DELAYED). Car, dans ce cas, l'insertion sera
faite dans un
        autre thread, qui n'aura pas le verrou. 

        Généralement, il n'y a pas besoin de verrouiller les tables, car
les mise à jour UPDATE sont atomiques : aucun autre thread ne peut
interférer
        avec la commande en cours d'éxécution. Il y a toutes fois,
quelques cas où il est bon de verrouiller une table : 

              Si un grand nombre d'opération vont être menée sur un bon
nombre de table, il est plus rapide de verrouiller les tables utilisées.
              L'inconvénient, bien sur, est qu'aucun autre thread ne
pourra accèder aux informations, ni les modifier. 
              MySQL ne supporte pas d'environnement transactionnel, donc
il faut absolument verrouiller une table, pour s'assurer qu'au autre
              thread n'intervient entre une commande SELECT et une
commande UPDATE . L'exemple ci-dessous montre comment exécuter une
              transaction : 



        mysql> LOCK TABLES trans READ, customer WRITE;
        mysql> select sum(value) from trans where customer_id= some_id;
        mysql> update customer set
total_value=sum_from_previous_statement
                   where customer_id=some_id;
        mysql> UNLOCK TABLES;

        Sans la commande LOCK TABLES, il se peut qu'un autre thread
insère une nouvelle ligne dans la table trans entre les deux commandes
SELECT
        et UPDATE .

La gestion des verrous sous MySQL est inblocable. Cela est réalisé en
demandant toujours tous les droits, en même temps, au début de la
        requête, et en verrouillant toujours les tables dans le même
ordre. 

        La méthode de verrouillage pour les verrous en écriture (WRITE )
est la suivante : 

              Si il n'y a pas de verrous sur la table, MySQL la
verrouille. 
              Sinon, il ajoute une demande de verrous dans la queue
d'attente. 

        La méthode de verrouillage pour les verrous en lecture (READ)
est la suivante : 

              Si il n'y a pas de verrous sur la table, MySQL la
verrouille. 
              Sinon, il ajoute une demande de verrous dans la queue
d'attente. 

        Quand un verrou est libéré, le verrou est rendu disponible pour
les threads de la queue d'attente d'écriture, puis dans la queue
d'attente de
        lecture. 

        Cela signifie que si vous avez de nombreuses modifications sur
une table, les commandes SELECT devront attente qu'il n'ya ait plus de
        modifications en attente pour être satisfaites. 

        Pour éviter ce genre de problème, vous pouvez rassembler toutes
vos insertions dans une table temporaire, et faire une mise à jour
importante
        de toute la table temporaire dans la fixe, une fois de temps en
temps. Cela se réalise avec le code suivant : 

        mysql> LOCK TABLES real_table WRITE, insert_table WRITE;
        mysql> insert into real_table select * from insert_table;
        mysql> delete from insert_table;
        mysql> UNLOCK TABLES;

A+ Yann

webconcepteur
foudenuke.org http://foudenuke.org/foudenukefr/
webmaster
Independant Technologies http://it.forez.com
Celticbrothers http://celticbrothers.poulp.org


Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft?
Rendez-vous sur "http://www.mandrakestore.com";

Répondre à