Discussion :

[Tanhys]

Bonjour, bonjour, bonjour tout le monde !!

Voilà, je viens vous parler d'un problème que je rencontre actuellement avec AJAX multithreads (mode asynchrone en fait).

Voici ce qui se passe:
Des éléments de mon site envoient plusieurs requêtes XMLHTTPRequests en parallèle, vers un même script PHP qui récupère les variables de session de l'utilisateur courant. Il arrive de temps à autre que la fonction "session_start" plante car elle n'a pas le droit d'ouvrir le cookie de session... car il y a un lock dessus :-(

Donc, j'imagine que ce problème survient quand 1 session_start survient trop rapidement après un autre session_start pour le même utilisateur.

Du coup, j'ai le sentiment que le mariage AJAX et sessions PHP ne font pas bon ménage. Est-ce que je me trompe ? Est-ce que quelqu'un a déjà eu ce problème ? L'a-t-il résolu ? Voici quelques questions que je me pose.

Je n'ai rien trouvé sur ce sujet... alors si quelqu'un a déjà rencontré ce problème, qu'il n'hésite pas à partager ses griefs avec moi ;-), Et s'il a trouvé une solution: MERCI de m'en faire part !!


Merci en tout cas de m'avoir lu ;-)

[tthierry]

>Donc, j'imagine que ce problème survient quand 1 session_start survient trop rapidement après un autre session_start pour le même utilisateur.

c'est ça, php lock les sessions et le problème existe également avec les frames.

ce qui m'étonne c'est que tu dises que ça plante, l'expérience que j'en ai serait plutôt que php attend sagement que la session se libère (php5.x), ajax ou pas ajax.

pour améliorer les choses il est possible de libérer la session dès que tu as fini de la manipuler plutôt que d'attendre la fin du script :

http://fr2.php.net/manual/fr/functio...rite-close.php

ce type de problème avec les frames :
http://fr3.php.net/manual/fr/functio...tart.php#70235

[Tanhys]

Et bien en fait, en terme de plantage, ça n'est pas exactement ça... c'est plutôt que mon script continue, mais sans les variables de sessions, du coup... j'ai des warning d'accès à des méthodes d'objet qui ne sont pas des objets, etc. ;-)

En tout cas, merci beaucoup pour ce tuyau, j'vais voir si ça rétablit les choses ;-)

Je te tiendrai au courant, si tu veux ^^

[Tanhys]

Bon, alors en définitive, session_write_close ne résoud pas complètement mon problème, même s'il l'a énormément amélioré.
Tout ceci vient du fait que le script qui pose problème fait un session_start, récupère l'objet "Site Internet", puis, gère la requête de l'utilisateur, retourne le résultat, puis.... l'objet est à nouveau sauvegardé dans les variables de session. Donc forcément, je ne peux pas faire un session_write_close avant la fin du traitement, qui malheureusement peut prendre un peu de temps.

Du coup, voici comment j'ai résolu TOTALEMENT mon problème:

une table sessions (session_id, session_status) dans la base de donnée. Le session_id est stocké désormais dans mon objet site et toute requête construite depuis l'interface client, envoie ce fameux session_id au script serveur. Du coup, je peux récupérer le statut du cookie stocké dans la base de donnée.
S'il est "locked", alors je fais une boucle qui fait patienter le script 500ms avant de revérifier si le lock a été libéré (toujours dans la base de données).

C'est une solution qui ralentit quelque peu les traitements, c'est certain, mais qui au moins, à le mérite de ne jamais planter. De plus, si jamais votre base de données est inaccessible (serveur down)... on peut gérer le problème sans soucis et avertir l'utilisateur que le serveur ne semble pas répondre. Il faut bien penser aussi à ne pas boucler indéfiniment, et prévoir une sortie avec message d'erreur également.

Voici le code utilisé:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
require_once("../functions.inc.php");
//Début de l'inclusion de toutes les classes nécessaires avant le début de la session
require_once("../config.inc.php");
$classes_dir = getAbsolutePath()."classes";
if(is_dir($classes_dir))
{
	$dh= opendir($classes_dir);
	while ($fichier = readdir ($dh))
	{
	    if ($fichier != "." && $fichier != ".." && !is_dir($fichier) && stripos($fichier, ".class.php") > 0)
		{
 
	        require_once(getAbsolutePath()."classes/".$fichier);
	    }
	}
	closedir ($dh);
}
else
{
 
}
//fin de l'inclusion des fichiers .class.php
 
//Récupération des paramètres de la requête utilisateur
$object = $_POST["object"];
$id     = $_POST["id"];
$invoke = $_POST["invoke"];
$params = $_POST["params"];
$session_id = $_POST["session_id"];
 
 
//début du traitement du script avec gestion du lock de session
if($session_id != "")
{
	dbConnect();
	$query = "select session_id, session_status from sessions where session_id = '".$session_id."'";
	$resId = runQuery($query);
	$resCount = resCount($resId);
	if($resCount > 0)
	{
		$session = moveNext($resId);
		if($session["session_status"] == "locked")
		{
			$query = "select session_id, session_status from sessions where session_id = '".$session_id."'";
			while($resCount > 0 && $session["session_status"] == "locked")
			{
				usleep(500);
				$resId = runQuery($query);
				$resCount = resCount($resId);
				if($resCount > 0)
				{
					$session = moveNext($resId);
				}
			}
		}
		$query = "update sessions set session_status='locked' where session_id='".$session_id."'";
	}
	else
	{
		$query = "insert into sessions (session_id, session_status) values ('".$session_id."', 'locked')";
	}
	runQuery($query);
	session_start();
	$internetSite = $_SESSION["site"];
 
	echo $internetSite->updateSite($object, $id, $invoke, $params);
	$_SESSION["site"] = $internetSite;
	session_write_close();
	$query = "update sessions set session_status='unlocked' where session_id='".$session_id."'";
	runQuery($query);
}

Je n'ai pas fini le script... mais dans l'idée, ça sera ça que j'utiliserai...

[tthierry]

>Et bien en fait, en terme de plantage, ça n'est pas exactement ça... c'est plutôt que mon script continue, mais sans les variables de sessions, du coup... j'ai des warning d'accès à des méthodes d'objet qui ne sont pas des objets, etc.

bizarre, je n'ai pas du tout ce comportement, le script bloque à session_start() et attend.

mais dit moi si je me trompe.
ta solution revient à effectuer des requêtes synchrones vu que tu vas traiter un script avant d'en entamer un second.

si c'est le cas il existe la solution d'un pool de requête ajax à mettre en place côté client et qui me semble un peu plus simple.
l'idée serait de mettre en attente une requête tant que la précédente n'est pas terminée.

sinon il existe aussi une autre méthode pour traiter les sessions qui ne produit aucun lock (donc à chacun de gérer les problèmes d'intégrité), mais necessite la compilation de php avec "with-mm=DIR" (elles seront gérées en mémoire partagée) :

http://www.zend.com/tips/tips.php?id=164&single=1

+

[Tanhys]

Oui, en effet, c'est quasiment du synchrone, sauf si lors de mon script, je libère la session avant la fin de l'éxécution totale du script en cours. On pourrait très bien imaginer que dans mon script, que je récupère l'objet Site Internet, que j'appelle les différentes méthodes qui conviennent, que je sauvegarde l'objet, libère la session et continue de faire d'autres traitement de présentation ou que sais-je... du coup, mon script 1 n'est pourtant toujours pas terminé que mon script 2 peut néanmoins débuter.

Autre différence avec le mode synchrone de l'objet XMLHTTRequest, ce dernier bloque le navigateur côté client tant qu'il n'a pas reçu la notification de fin de traitement côté serveur.... empêchant alors toute navigation.... ça a souvent tendance à freezer le navigateur, ce qui est à proscrire. Quitte à empiler des actions dans un stack quelconque, j'péfère autant que ça se fasse côté serveur.

Maintenant, je reste néanmoins tout à fait d'accord avec toi sur le fait que OUI, c'est bien du synchrone.

Merci pour les infos concernant la récupération partagé des cookies de sessions. Mais malheureusement, puisque mon projet est destiné à être hébergé sur un serveur mutualisé classique... je ne sais pas si je pourrais trouver l'environnement adéquat qui me permettrait de faire ça.