15-09-2011, 11:09 PM
je n'y connais pas assez, ni en serveur ni en transactions SQL mais imaginon un doubleclic
1 ere requete clic, tu regardes en session ton timestamp, il est ok
2 nde requete, idem => les deux requetes passent
1 ere requete, l'insert se fait,
2 eme l'insert se fait
1 ere , mise a jour de la session
2 nde, mise à jour de la session
3 eme clic
3 eme requete, timestamp pas ok, ça passe pas.
C'est difficile à imaginer car d'une part je suppose que PHP gère la session d'une manière plus consistante, et de deux le double clic n'est pas assez rapide ! (je compte à l'arrache, en 1 seconde je fais 7 clics à la vitesse de mon double clic normal.
Bon, donc si maintenant au lieu de stocker ton timestamp en session tu le mets dans la table où tu fais tes insert. (je ne sais pas quelles sont tes données, donc je ne sais pas si c'est judicieux;
1er clic, début de requete
2 eme clic, début de requete
1 ere requete début de transaction blocante en lecture (est-ce que ça existe ?)
2 eme requete : table bloquée, on patiente
1ere requete, on regarde si le timestamp dans la tables est ok ? il l'est, on fait l'insert et on met a jour le timestamp dans la table
1 ere requete toujours, on libère la table en mettant fin à la transaction
2 eme requete, début de transaction, on lit le timestamp, il est trop récent, on laisse tomber.
(par contre, logiquement le navigateur devrait afficher le résultat de la seconde requete, c'est dommage)
Voilà je ne sais pas si ce que je raconte est vraisemblable car je ne pense pas que ça se passe comme ça mais c'est une idée à explorer.
Si tu gères toi même la session PHP avec ta base de données (comme j'ai vu que tu en parlais sur des topics), tu peux également faire une transaction au niveau de la session pour empecher la seconde requete de lire le timestamp avant que la première ne l'ai mis à jour.
Dans les deux cas, même si la seconde requete arrive au serveur avant la première (c'est possible), ça marche aussi.
À condition de pouvoir bloquer une table en lecture lors des transactions et bien sur à condition de n'avoir pas trop de demandes sur cette table car la transaction la bloque pour tout le monde
1 ere requete clic, tu regardes en session ton timestamp, il est ok
2 nde requete, idem => les deux requetes passent
1 ere requete, l'insert se fait,
2 eme l'insert se fait
1 ere , mise a jour de la session
2 nde, mise à jour de la session
3 eme clic
3 eme requete, timestamp pas ok, ça passe pas.
C'est difficile à imaginer car d'une part je suppose que PHP gère la session d'une manière plus consistante, et de deux le double clic n'est pas assez rapide ! (je compte à l'arrache, en 1 seconde je fais 7 clics à la vitesse de mon double clic normal.
Bon, donc si maintenant au lieu de stocker ton timestamp en session tu le mets dans la table où tu fais tes insert. (je ne sais pas quelles sont tes données, donc je ne sais pas si c'est judicieux;
1er clic, début de requete
2 eme clic, début de requete
1 ere requete début de transaction blocante en lecture (est-ce que ça existe ?)
2 eme requete : table bloquée, on patiente
1ere requete, on regarde si le timestamp dans la tables est ok ? il l'est, on fait l'insert et on met a jour le timestamp dans la table
1 ere requete toujours, on libère la table en mettant fin à la transaction
2 eme requete, début de transaction, on lit le timestamp, il est trop récent, on laisse tomber.
(par contre, logiquement le navigateur devrait afficher le résultat de la seconde requete, c'est dommage)
Voilà je ne sais pas si ce que je raconte est vraisemblable car je ne pense pas que ça se passe comme ça mais c'est une idée à explorer.
Si tu gères toi même la session PHP avec ta base de données (comme j'ai vu que tu en parlais sur des topics), tu peux également faire une transaction au niveau de la session pour empecher la seconde requete de lire le timestamp avant que la première ne l'ai mis à jour.
Dans les deux cas, même si la seconde requete arrive au serveur avant la première (c'est possible), ça marche aussi.
À condition de pouvoir bloquer une table en lecture lors des transactions et bien sur à condition de n'avoir pas trop de demandes sur cette table car la transaction la bloque pour tout le monde