Lorqu'un script PHP s'execute côté serveur(Apache), peut t'on être sûr que le script va s'executer de A à Z sans interruption.  
Va t'il garder la main ? Un exemple :
Voici un script qui réalise les étapes suivantes :
1) Récupération des données X1 et X2 dans une table.
2) Selon X1 et X2, executer l'Action_mise_à_jour 1  
ou l'Action_mise_à_jour 2.
Si les valeurs X1 ou X2 venaient à changer pendant l'execution du script, l'action à réaliser serait totalement différente.

pas tout compris ....

cela dépends de ton curseur, si tu utilise un curseur statique, cela ne devrait pas poser de problème, par contre ce qui était vrai au moment où tu as fait ta requête ne le seras plus forcément une seconde plus tard.

 
Lorsque plusieurs scripts sont envoyés au serveur dans un laps de temps très court, est-ce que le serveur les execute un par un et dans l'ordre d'arrivée ?

bonne question que je ne m'etais jamais posé ........
mais dans quel cas as tu besoin de cette ordonnance ?

 
Le serveur execute plusieurs accès pages php en même temps (je les voit dans mon top). Si tu a besoin de garantir l'intégrité dans le temps, utilise des transaction (très bien), ou des semaphores (bien si le temps est très court).

je ne pense pas ....  
 
ex : 2 scripts dont un avec un sleep ...  
 
le 2eme s'executera avant le 1er a moins que le 2eme n'ai besoin du 1er !

kadreg > c'est quoi les semaphores ?

Je crée une base de données de support médias (vidéos, posters, diapos...) Je gère les emprunts.
A un moment donné, deux personnes ne peuvent pas emprunter la même vidéo.

MYSQL ne gère pas les transactions.

rollback et commit ?

as-tu calculer la probabilité que deux personnes choisissent la même vidéo à la même seconde (voir moins), si celle-ci est quasi-nulle est-ce bien nécessaire de se prendre la tête

Rollback et commit ?
Je ne sais pas. Avis aux autres programmeurs...

La proba est très petite mais ca foutrait la merde dans la BD !

Voici un bout de la doc MYSQL qui pourrait me servir et vous servir car je pense que ma question n'était pas bête...
MYSQL ne gère pas les transactions et ROLLBACK. Cela va changer dans les prochaines versions. Par contre on peut vérouiller les tables. Je n'y avais pas pensé.
 
7.23 LOCK TABLES/UNLOCK TABLES
LOCK TABLES Nom_table [AS alias] {READ | [LOW_PRIORITY] WRITE}
[, Nom_table {READ | [LOW_PRIORITY] WRITE} ...]
...
UNLOCK TABLES
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 le 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

 
Pas accessibles depuis PHP dans le cadre de mySql.

 
La possibilité de créer des zones critiques dans un programmes, et tu est sur que, a tous moment, une seule instance de ton programme sera dedans.
 
Si une seconde instance à besoin de rentrer dans la zone critique, elle attendra que la première en sorte.

lock/unlock : veilles a bien de-locker tes tables avant chaque nouvelle action !!!!  
 
je suis deja tombé dans le panneau !!  un oubli diront nous

 
Tiens, au fait, quelqu'un peut m'expliquer cette page de la doc de mySql, c'est lié :
 
http://www.mysql.com/doc/C/O/COMMIT.html

nicotine a écrit a écrit : lock/unlock : veilles a bien de-locker tes tables avant chaque nouvelle action !!!!     je suis deja tombé dans le panneau !!  un oubli diront nous

 
Attention à la montée en charge du serveur, j'ai eut des surprise avec le script timeout

en positionnant le flag autocommit à 0 , tu es en safe mode , cad que tu peux revenir a l'etat precedent en utilisant rollback.
 
honnetement : je ne m'en suis jamais servi meme si a l'air bien pratique
 
j'avais quand meme fait une tentative : je devais faire un log analyzer mais il y avait enormement de requetes sql que j'executais au coup par coup (au lieu de les stockes dans un fichier et de faire une seule action finale).
Le probleme , j'etais en cours de dvlpt et a chaque bug , je devais purger les derniers entrées ......
ma methode etait un dump avant de lancer le binaire.
 
avec le commit/rollback , tu t'affranchis de cette methode

Je me suis mal expliqué.
 
mysql supporte cette technique que dans le cas de tables transactions safe. Qu'es-ce qu'une table transactions safe ?

les manip' sont stockés (si j'ai bien compris) dans un fichier de log binaire.  les tables ne sont pas mises a jour avant un ordre final.
 
mais j'ai jamais reussi a faire correctement la manip (ca remonte a un an).

mais je sais pas si ca repond a ta question

 
te plains pas tu bosses sous mySQL y'en a qui bosse sur SQLserveur 7 ....
 
 

[edit]--Message édité par ajnag--[/edit]

 
Y'en a qui bossent sous cloudscape