J'ai une application mobile, qui fait une demande . Il attend 63 secondes (le backend PHP peut fonctionner pendant environ 62 secondes) pour une interaction utilisateur à l'autre extrémité. Maintenant, si dans l'attente, je décide d'abandonner cette demande, alors j'appelle et il y a le problème. Même Tho I Des idées? P> JQuery 1.8.2, JQuery Mobile 1.2.0, PhoneGap 2.0.0 et 2.1.0, Apache 2 , Linux, PHP 5.3 P> P> jQxhr.abort () code>. Dans le gestionnaire d'erreurs, je manipule / distinct déjà entre des erreurs réelles et des avorts, cela fonctionne. Juste après l'abandon, je veux envoyer un autre appel d'API au serveur pour attacher les extrémités desserrées et assurez-vous que ma demande d'annulation est enregistrée. P>
Abort () Code> La première demande, le script php est toujours en cours d'exécution sur le serveur, ce qui ne poserait pas un problème si elle exécutait également la deuxième demande, ce qui le ferait arrêter et mourir (). Mais cela ne se passe pas. La deuxième demande ne se produit pas tant que les premières finitions. P>
3 Réponses :
La méthode Abort code> ne résilier pas le processus de serveur, il ne cessera que le côté client attend la réponse du serveur. P>
La deuxième demande est également une demande AJAX (). Pour être plus précis, lorsque le premier est envoyé, je montre une popup avec un compte à rebours et un bouton d'annulation. Lorsque vous appuyez sur le bouton, la première requête est annulée et la seconde est envoyée. Et c'est à ce moment que je dois attendre que le 1er appel de l'API (demande) soit terminé, la 2ème demande passera trop tard à ce moment-là.
Il semble que je manquai dans la bonne vieille séances PHP par rapport au problème des demandes d'Ajax. En fait, mon patron a découvert cette question en googling certaines expressions que je n'ai jamais pensées. J'utilise Zend Framework dans le back-end et commence automatiquement un espace de noms de session, donc dans la méthode Preispatch () de mon contrôleur d'API que je devais mettre dans une @session_write_close (); ligne, et comme si par magie, cela fonctionne comme un charme. P>
merci arun pour votre réponse rapide, c'est le plus apprécié. P>
Donc, en bref: Si vous utilisez Zend Framework ou Session_autoStart ou d'autres moyens de démarrage, ils ne voleront pas avec des demandes parallèles Ajax. P>
Données de session strong> est généralement quand par ex. Utilisation de cadres de cadres avec des sessions, vous ferez l'expérience des cadres en chargement d'un par un en raison de ce verrouillage. Vous pouvez réduire le temps strong> nécessaire pour charger tous les cadres Vous pouvez donc utiliser des sessions dans des scripts Ajax avec
mais: em> Je l'utilise de cette façon dans tous mes scripts Ajax pour implémenter la manipulation de la session et em> permettant une demande parallèle p> session_start (); code> (peut-être traité automatiquement) suivi immédiatement (plus vite possible) par
session_write_close (); code> p> p> p>
session_write_close (); code> "finira" la session en cours et stockera les données de session. P>
session_id () code> sera toujours livré le correctif (actuel) phpsessid afin de pouvoir obtenir un accès en écriture à la session en cours en faisant simplement
session_start () code> à nouveau à tout moment, vous en avez besoin. p>