Forum d'entraide PHPFrance

Bonjour à tous !!

Je suis actuellement sur un gros projet mais j'ai constaté un bug quand plusieurs utilisateurs ont accès à la même page ou qu'un même utilisateur par mégarde ouvrir 2 fois la même page
Par exemple j'ai dans mon projet une page qui s'appelle encodage de points pour des élèves et il peut y avoir plusieurs professeurs pour une même classe
Si un professeur encode une interrogation et que le même professeur est sur cette page en même temps il faudrait que cette page se rafraichisse automatiquement dès qu'une action a été réalisée

Que proposez-vous ?

Merci beaucoup amis programmeurs !

Salut,

J'ai pas tout à fait saisi ton souci. Si deux utilisateurs sont sur la même page et que l'un fait des modifs, l'autre puisse voir ses modifs en temps réel alors que lui même édite la même fiche ? La solution la plus appropriée serait de faire des appels Ajax tous les N secondes. Le souci -> les perfs risquent de chuter....

Ce qui est souhaitable de faire est de mettre un système de verrous. Quand un utilisateur veut faire une modif, il verrouille la fiche (champ tiny int dans la table = 1). Quand il a fini de faire ses modifs, il déverrouille la fiche (champ tiny int dans la table = 0).

C'est pas Facebook hein, faire des requêtes Ajax toutes les 10 secondes n'a aucune influence sur la performance d'un site que deux ou trois personnes visitent en même temps.

C'est pas Facebook hein, faire des requêtes Ajax toutes les 10 secondes n'a aucune influence sur la performance d'un site que deux ou trois personnes visitent en même temps.

oui, je le conçois et encore.... Admettons que cette application soit pour une/les académie(s) régionale(s). (...)

D'une manière générale, je déconseille cette solution. Trop de risques pour pas grand chose. C'est le même problème que 2 users sur un même fichier avec la même branche d'un svn. Paye tes conflits et ensuite paye ton merge.....

Donc verrouiller la fiche est la solution la plus sûre, pragmatique et efficace selon moi.

Je n'ai pas l'impression qu'il s'agit là d'une gestion de conflit. D'ailleurs je ne vois pas en quoi une malheureuse requête Ajax toutes les 10 à 30 secondes qui ne renvoie rien du tout (ou pas souvent) en long polling est une charge intensive.

J'ai donné les deux solutions et donner mon avis.

La 1ère solution qui semble sympa peut s'avérer un gros bogue :
* Les users A et B enregistrent en même temps la fiche. Quel enregistrement sera pris en compte ?
* User A n'a pas activé le javascript sur sa machine pour des raisons de sécurité par exemple. A ne pourra pas éditer correctement la fiche
* XX users sur la même fiche + XX users sur la même application.... Le serveur n'est pas une bête de course....

La 2e solution :
* user B veut éditer la fiche X alors que user A est en train d'éditer cette dernière. User B sera redirigé vers l'index et aura une notification "la fiche est en cours d'édition, veuillez réessayer un peu plus tard". A enregistrera correctement la fiche.
* user A n'a pas activé le JS. Ce n'est pas un souci puisque cela fonctionnera forcément
* 1 user la fiche. Les autres attendent patiemment. Le serveur sera nettement moins mis à contribution.

Dans la 2e solution, tout résidra dans ce système de verrouillage de fiche. Ce qui veut dire qu'il faudra bien gérer cela. Lorsque le user cliquera sur édition, il y aura automatiquement 2 requêtes :
* UPDATE
* SELECT (gestion fine du select) :
° Est ce qu'il y a une donnée ?
° Est ce que la fiche est verrouillée ?
Pour cela, je préconise un système de transaction :
* START TRANSACTION/BEGIN TRANSACTION
* COMMIT
* ROLLBACK

Au passage, la table devra être en InnoDB bien sûr