Titre: Flux concurrentiels
Posté par: xplosion le le 11-02-2005 a 16:15:50
Bonjour tout le monde,
jutilise MySQL 3.23.49-max-nt et je voudrais savoir commence est gerer le fait que plusieurs utilisateur modifient en meme temps la meme table... Est ce que ca planter, est ce que ca va generer une page d'erreur, ... bref comment ca ce passe? Merci d'avance. |
Titre: Re:Flux concurrentiels
Posté par: gobmok le le 15-02-2005 a 18:35:09
c'est ce qui s'appelle du multi-threading en programmation: en gros le programmeur divise certaines partie de programme en thread, celle-ci sont comme des fonctions, mais peuvent s'éxécuter à des moments différents et sont indépendantes du programme.
chacune des opérations (ajouter un nouvel utilisateur, modifier une donnée, pour une base de donnée, ou additionner quelque chose pour un programme classique) se font une à une et sont stockés dans une queu(en fait il y a plusieurs queus de différents niveaux) que le processeur gére
chacune de ces opérations ont des niveaux d'importance, un thread(une opération) au niveau plus important passera avant les autres( comme quand tu appuyes désespéremment sur ctrl-alt-del, logiquement, c'est une opération prioritaire et s'éxécutera avant un programme déja lancé )
de plus l'avantage de ce systéme c'est que tant que le thread est dans la queu, on peut l'arréter, le mettre en pause pour l'activer plus tard.
ta base de donnée utilise ce systéme à chaque fois qu'un utilisateur active un script qui modifie une base de donnée, cette modification crée un thread qui est stocké sur le serveur dans la queu de thread (générallement en mém cache)et ceux-ci sont éxécutés une à une selon leur importance
c'est comme ça qu'aucune collision(deux informations se réalisant en même temps) ne se passe pour ta base de donnée |
Titre: Re:Flux concurrentiels
Posté par: tavman le le 16-02-2005 a 19:56:48
Sauf qu'il y a un léger soucis... c'est que souvent, les serveurs laissent pas 100 modifications à faire dans la queue (simple raison de sécurité pour pas saturer le serveur...) Donc en fait, si jamais t'as 1000 requetes à faire en même temps dans une base de donnée, tu risque d'en avoir pas mal qui vont pas s'executer (enfin si j'ai bien compris le truc).
Mais bon, tu peut te dire que t'as une bonne marge quand même... mais faut savoir que c'est brider.
Petite précision : je suis pas du tout spécialiste en la matière et je peut me tromper... mais il me semble que c'est bien comme ca que le truc est fait. |
Titre: Re:Flux concurrentiels
Posté par: gobmok le le 16-02-2005 a 23:27:44
éxact, dans le fichier de configuration de MysQL:
set-variable = thread_stack=64K
elle est aussi limité dans le nombre de connecté en même temps, ainsi que dans la taille de ses tables( ceci pour mysql j'en suis sur, pour oracle, c'est toi qui décide de la taille maximum pour chaque table par ex )
je tiens à signaler que MySQL posséde également un service de journalisation de ces opérations. Celui-ci valide une opération lorsque celle-ci est terminé, c'est ce qui permet à la bd de 'revenir en arrière', le systéme n'est pas infaillible, et ill 'oublie' certaines de ces opérations dont il n'a pas de détail suffisant ( note que la façon dont MySQL récupère ses données sont variables selon la table que tu as choisi en MySQL, certaines n'ont même pas de systéme de journalisation )
mais ne me faites pas dire ce que je n'ai pas dit: le multithreading n'est pas seulement utile à MySQL, mais aussi apache, ie, un jeu vidéo, et tout autres programme un peu neuf qui soit, c'est juste un mécanisme qui permet d'augmenter la capacité du processeur, puisqu'il permet de gérer et subdiviser les taches qu'il a à réaliser, et donc également permet de gérer des services multiclient( donc serveur web, jeu en ligne, etc ) avec grande efficacité en évitant les problèmes de collision des données dans le temps
pour compléter ma réponse du premier message:
chacune de ces opérations s'éxécutent de manière asynchrone (indépendante dans le temps) ce qui fait qu'il y a parfois de légère incohérence:
première opération dans le temps: +10% dans commande.produit.prix
deuxième opération dans le temps: +5 dans commande.produit.prix
imaginons la valeur de base:10
si tu applique dans l'ordre l'opération tu obtiens:16
cependant , des opérations peuvent se passer dans le désordre, et dans ce cas tu obtiens: 16,5
sache que quelques soient la façon dont les opérations se déroule: LES DEUX SONT CONCIDERE BONNES
tant qu'une opération se déroule en entier(celle-ci pouvant comporter plusieurs petites opérations qui elles ont un ordre précis) et validé par le systéme de journal cité plus haut, l'opération est considéré comme valide
j'espère que ce dernier message aura servi à quelqu'un par ce que là je crois que je me suis un peu emporté.......... |
Forum-webmaster | Actionné par YaBB SE
© 2001-2003, YaBB SE Dev Team. Tous droits réservés.
|