Discussion :

[Traroth2]

Bonjour,

Je viens d'avoir un bug très bizarre dans une application Web déployée sur un serveur Tomcat : Lors de l'insertion de données en base, un des champs contenait une information provenant clairement d'une autre session (en gros, l'identifiant ne correspondait pas au bon utilisateur). C'est la première fois que je vois un truc pareil et je voulais savoir si quelqu'un avait déjà affronté un problème de ce genre. Toute aide bienvenue.

Tomcat 5.0.28
JDK 1.5.0_12
serveur Debian

Edit : J'ajoute que, comme c'est une application en production, c'est un problème qui semble pour l'instant unique. La même opération semble très bien se passer le reste du temps. L'identifiant (mauvais) inséré en base est celui d'un autre utilisateur, qui s'est connecté au même moment.

[Traroth2]

En fait, c'est un problème pas du tout unique, et qui est en train de pourrir notre base de données. Bon, j'ai un workaround, mais si quelqu'un a une solution, ça m'aiderait énormément.

Quand on lit des threads comme celui-ci dans les archives de la mailing-list Tomcat, ça fait froid dans le dos. Je suis en train de me demander si la vraie solution, ça va pas être de switcher vers Resin...

[the-gtm]

Le lien que tu as posté ne parle pas de ça : le problème décrit est que si deux requêtes modifient en même temps la même session, il y a un problème de concurrence. Cela peut se produire un utilisateur clique sur plusieurs liens en même temps rapidement. Quand le cas se produit on aboutit à une boucle infinie.

Peut être que tu peux nous montrer comment tu accède à la session et comment tu mets les paramêtres dedans?

[Traroth2]

Bien sûr :


Ajout d'attribut en session :

Code :

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

1
2
3
4
5
6
 
session = request.getSession();
...
synchronized(session) {
	session.setAttribute("utilisateur",user);
}

lecture de paramètre en session :

Code :

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

1
2
3
4
5
6
 
synchronized(session) {
	utilisateur = (Utilisateur)session.getAttribute("utilisateur");
	groupe = (Groupe)session.getAttribute("groupe");
	compte = (Compte)session.getAttribute("compte");
}

retrait de paramètre de session :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
synchronized(session) {
	Utilisateur utilisateur = (Utilisateur)session.getAttribute("utilisateur");
	Groupe groupe = (Groupe)session.getAttribute("groupe");
	ConnexionInfo cnxInfo =  ConnexionInfo)session.getAttribute("uploadCounter");
	try {
		if (cnxInfo!=null) {
			pm.sendUploadNotification(utilisateur, groupe, cnxInfo);
			session.removeAttribute("uploadCounter");
		}
	} catch (Exception e) {
				logger.error("ControllerServlet.disconnect : Problème dans l'envoi des notifications d'upload",e);
	}
}

Il y a aussi ce lien.

[Traroth2]

Bon, il y a du nouveau, ça peut intéresser pas mal de gens. En démontant fastidieusement le fonctionnement de mon code, j'ai trouvé que c'est à un endroit bien précis de mon code que le bug se produit, et c'est pour le moins déroutant.

Une de mes servlets sert à uploader des fichiers, en utilisant Jakarta Commons Upload (l'application est un site de partage de photos). Je récupère des données en session au début de la servlet :

Code :

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

1
2
3
4
5
6
 
synchronized(session) {
        utilisateur = (Utilisateur)session.getAttribute("utilisateur");
        groupe = (Groupe)session.getAttribute("groupe");
	compte = (Compte)session.getAttribute("compte");
}

Ensuite, on execute les différents traitements liés à l'upload (je vous épargne les 3 pages de code). Au final, pour le calcul des quotas, afin d'éviter une désynchronisation avec la base (Mysql 5) en cas d'uploads concurrents sur le même compte depuis plusieurs postes, on recharge les beans contenant les informations liés aux quotas (sans ça, les différentes connexions concurrentes au site du même utilisateur vont écraser leurs données respectives dans la base) :

Code :

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

1
2
3
4
5
6
7
8
9
 
groupe = gm.loadBean(groupe.getId());
compte = cm.loadBean(compte.getId());
session.setAttribute("groupe", groupe);
session.setAttribute("compte", compte);       
 compte.setDiskSpaceUsed(compte.getDiskSpaceUsed()+diskSpace-currentDiskSpace);                           
 groupe.setDiskSpaceUsed(groupe.getDiskSpaceUsed()+diskSpace-currentDiskSpace);
cm.saveBean(compte);
gm.saveBean(groupe);

Et là, tenez-vous bien, les méthodes loadBean, qui lisent les données en base, lisent bien les bonnes données, mais visiblement, en session, il se passe des choses bizarres quand on fait un setAttribute. Evidémment, les attributs en question sont déjà setté en session, mais la spec précise bien que dans ce cas, l'ancien objet est remplacé par le nouveau. Je me suis aussi amusé à afficher le sessionId et il est toujours correct. Même en retournant le problème dans tous les sens, c'est inexplicable. Et ça se produit avec Tomcat comme avec Resin. C'est peut-être Commons Upload qui fait tout péter ?

Si quelqu'un a une explication, je suis preneur, même si maintenant que j'ai trouvé l'origine du problème, j'ai pu le contourner.

[the-gtm]

Tu ne lance pas des threads par hasard?