7
votes

JQuery Ajax Abort et nouvelle demande en succession rapide

J'ai une application mobile, qui fait une demande xxx

. 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 jQxhr.abort () . 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.

et il y a le problème. Même Tho I Abort () 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.

Des idées?

JQuery 1.8.2, JQuery Mobile 1.2.0, PhoneGap 2.0.0 et 2.1.0, Apache 2 , Linux, PHP 5.3


0 commentaires

3 Réponses :


0
votes

La méthode Abort ne résilier pas le processus de serveur, il ne cessera que le côté client attend la réponse du serveur.


1 commentaires

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



1
votes

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.

merci arun pour votre réponse rapide, c'est le plus apprécié.

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.


0 commentaires

3
votes

Quelques informations sur: Parallel-Ajax vs Verrouillage de la session Apache

Données de session est généralement stockée après votre script terminé , mais comme les données de session sont verrouillées pour éviter les écrivies simultanées Un seul script peut fonctionner sur une session à tout moment .

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 nécessaire pour charger tous les cadres en finissant la session dès que possible .

Vous pouvez donc utiliser des sessions dans des scripts Ajax avec session_start (); (peut-être traité automatiquement) suivi immédiatement (plus vite possible) par session_write_close ();

session_write_close (); "finira" la session en cours et stockera les données de session.

mais: session_id () 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 () à nouveau à tout moment, vous en avez besoin.

Je l'utilise de cette façon dans tous mes scripts Ajax pour implémenter la manipulation de la session et permettant une demande parallèle


0 commentaires