Gestion des scripts PHP sous Apache

Recherche :

Dernière réponse

Sujet : ******** Gestion des scripts PHP sous Apache ********

kadreg

ajnag a écrit a écrit :

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

Y'en a qui bossent sous cloudscape :lol:

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

kadreg

ajnag a écrit a écrit :

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

Y'en a qui bossent sous cloudscape :lol:

ajnag

linux2000 a écrit a écrit :

MYSQL ne gère pas les transactions.

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

:lol:

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

nicotine

mais je sais pas si ca repond a ta question :(

nicotine

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).

kadreg

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 ?

nicotine

kadreg a écrit a écrit :

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

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

kadreg

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 :D

kadreg

nicotine a écrit a écrit :

rollback et commit ?

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

lock/unlock : veilles a bien de-locker tes tables avant chaque nouvelle action !!!!

je suis deja tombé dans le panneau !! un oubli diront nous ;)

kadreg

nicotine a écrit a écrit :

kadreg > c'est quoi les semaphores ?

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.

kadreg

linux2000 a écrit a écrit :

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

Pas accessibles depuis PHP dans le cadre de mySql.

linux2000

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

linux2000

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

linux2000

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

duch	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

nicotine

rollback et commit ?

linux2000

MYSQL ne gère pas les transactions.

linux2000

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.

nicotine

kadreg > c'est quoi les semaphores ?

nicotine

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

nicotine a écrit a écrit :

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).

nicotine

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

linux2000

nicotine a écrit a écrit :

pas tout compris ....

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 ?

duch	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.

nicotine

pas tout compris ....

linux2000

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.