Discussion :

[gazelle]

Bonjour,

Je tourne en rond depuis 4 jours sur une problématique que je n'arrive pas à résoudre.

Je publie un évènement sur mon site Web pour lequel des utilisateurs peuvent s'inscrire.

- Dans mon cas, j'ai besoin de 2 utilisateurs seulement.
- Le site gère seul le fait que les 2 premiers inscrits auront le statut "accepté" d'office (premier arrivé : premier servi).
- 2 autres utilisateurs peuvent s'inscrire mais auront le statut "sur file d'attente".


Le problème :
- J'ai donc un premier utilisateur qui s'inscrit à 13h57, statut "accepté".
- J'ai ensuite l'inscription de 2 utilisateurs simultanés, à 14h01 (et 13 secondes exactement). Les deux obtiennent le statut "accepté" d'office alors que l'un d'eux aurait dû être sur file d'attente.
Les requêtes de vérification ayant lieu à la même seconde, tout était correct à ce moment précis...
Mais voilà, j'ai 3 personnes dont le statut est "accepté" au lieu de 2...


Je précise que le système a toujours bien fonctionné jusque là, donc pour moi, aucun problème de code, tout a été vérifié. Sauf que là, c'est un cas bien particulier.

Auriez-vous une idée qui expliquerait cela?
Merci d'avance.

[Exia_]

Bonjour,

comment gère tu la vérification du nombre d'utilisateur étant accépté ?

De manière applicative ou une contrainte dans le SGBDR ?

[gazelle]

Bonjour,

Voici comment ça se passe d'un point de vue algo :
Dans ma table "évènement", j'ai un champs "statut_evt" qui définit quel statut les personnes auront à l'inscription (ce champs peut paraître inutile, mais j'en ai besoin).
Donc à la création d'un évènement, le statut par défaut est "accepté" :
statut_evt = accepte;

Tant que je n'ai pas atteint mon quota, ce statut ne change pas.

Quand une personne s'inscrit, je vérifie "statut_evt" et ensuite, je vérifie si son inscription atteindra le quota. Si c'est le cas, je change le statut de l'évènement :
"statut_evt" = "file d'attente",
puis j'inscrit mon utilisateur qui aura le statut "accepté".

Donc le prochain utilisateur aura le statut "file d'attente" (selon le champs de ma table "évènement" : "statut_evt").

Je ne sais pas si j'ai été assez claire...

[CinePhil]

Quand une personne s'inscrit, je vérifie "statut_evt"

Par une requête ?

ensuite, je vérifie si son inscription atteindra le quota.

Par une autre requête ?

Si c'est le cas, je change le statut de l'évènement :
"statut_evt" = "file d'attente",

Donc une autre requête !

j'inscrit mon utilisateur qui aura le statut "accepté".

Et encore une requête.

Entre temps, un autre utilisateur est venu s'inscrire avant que la requête de changement de statut n'ait eu lieu.

Tu devrais passer par une procédure SQL qui permettra de faire toutes les opérations en une seule transaction et en verrouillant les tables et le second utilisateur attendra que la première inscription soit terminée. Rassure-toi, ça va très vite et l'utilisateur physique derrière son écran ne sentira pas la différence.

[gazelle]

Merci CinePhil pour cette réponse, c'est un peu près ça à une requête près.
Je pense faire ça avec une transaction géré en PHP, car j'ai pas mal de condition intercalé entre mes différentes requêtes.
Est-ce que ça fonctionnera? (je n'ai jamais fait de transaction dans ma vie de développeur)

[ericd69]

salut,

la procédure stockée va te permettre d'encapsuler en elle toute la logique de décision et les requêtes, ça évite les allers-retours php/mysql et c'est plus facile à maintenir

les transactions ça n'a de sens qu'avec des tables en innodb sinon tu devras faire des lock/unlock mais eux sont sur une table entière... après il y a plusieurs niveau d'isolation dans les transactions, faut voir celui qui convient le mieux et ça dépend de comment tu gères justement le suivi... tu écriras des transaction plus efficacement dans une procédure et ça limitera beaucoup les risques de blocage de tables...