Discussion :

[kikijojo72]

Bonjour,

Voici mon contexte d'application :

Application J2EE sous Websphère avec :
- Struts pour la présentation
- Spring / Hibernate pour le métier
- Découpage en couche : Business Service et DAO

L'application tourne dans un contexte multi-utilisateurs. De ce fait, je souhaite avoir un contexte unique persistant pour chaque utilisateur contenant les informations propres à chaque utilisateur.

Du côté présentation, pas de problème. Je mets mon contexte en session :

Code :

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

request.getSession().setAttribute( "Contexte", contexte );

Le problème se pose du côté métier. Je n'arrive pas à avoir d'objet unique accessible partout dans le métier...

Mon premier essai consistait à stocker mon contexte dans une map multi-thread avec le Thread concerné comme clé :

Code :

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

maMap.get( Thread.currentThread() );

Problème : Avec Hibernate plusieurs Thread peuvent être exécutés pour une transaction... Je ne peux donc pas récupéré mon contexte dans certains cas !

Mon 2è essai s'orientait sur un singleton avec variable statique... Problème : Le singleton est unique pour tous les utilisateurs !

Bref, je suis perdu ! Je sais qu'il doit y avoir un moyen de faire ça sans avoir à passer mon contexte en paramètre de toutes mes méthodes métier mais je ne sais pas comment !!
Peut-être qu'avec Spring, il y aurait un moyen ?

Merci d'avance à tous pour votre aide...

[kikijojo72]

Personne n'a une petite idée à me proposer ?
Je suis vraiment en galère avec cette histoire...

[thelvin]

Je sais qu'il doit y avoir un moyen de faire ça sans avoir à passer mon contexte en paramètre de toutes mes méthodes métier mais je ne sais pas comment !!

Définir un id unique à ton contexte, maintenir une Map accessible statiquement qui contient tous les ids pointant vers tous les contextes actuellement viables.

C'est à peu près comme ça que marchent l'objet Session lui-même, au passage.
Mais il serait bien plus simple de juste passer le contexte partout, ou plus exactement, de construire des objets chargés de faire tes actions, et de passer ta session dans leur constructeur, pour qu'ils sachent qu'ils utilisent celle-là.

[kikijojo72]

Merci pour la réponse mais c'est pas pratique.
Ca impose de passer soit l'id généré soit le contexte en paramètre de toutes les méthodes.
Je pars d'un existant et les impacts d'un tel changement sont trop grands...

C'est pourquoi je cherche un autre moyen...

Mais pendant mes investigations, j'ai vu des choses sur le ThreadLocal. Visiblement, ca serait la solution à mon problème...

Qu'en pensez-vous ?

[thelvin]

Mais pendant mes investigations, j'ai vu des choses sur le ThreadLocal. Visiblement, ca serait la solution à mon problème...

Ben oui, mais tu avais dit qu'une même action n'était pas forcément liée à un même thread...

[-gma-]

Problème : Avec Hibernate plusieurs Thread peuvent être exécutés pour une transaction... Je ne peux donc pas récupéré mon contexte dans certains cas !

Est ce que tu es sûr de ça ? Les Session et Transaction d'Hibernate ne sont généralement pas thread safe.
Généralement une requête dans un container s'exécute dans un thread unique et dans ce cas tu peux utiliser le ThreadLocal pour pointer vers l'objet contexte au moment où tu as encore accès à la Session (dans un filtre de servlet par exemple)

[kikijojo72]

Les Session et Transaction d'Hibernate ne sont généralement pas thread safe.
Généralement une requête dans un container s'exécute dans un thread unique et dans ce cas tu peux utiliser le ThreadLocal pour pointer vers l'objet contexte au moment où tu as encore accès à la Session (dans un filtre de servlet par exemple)

C'est bien ça. En fait, j'ai mal localisé le problème. J'ai bien un Thread pour une transaction...

Donc il faut bien que j'utilise le ThreadLocal à chaque transaction pour transporter mes données issues du contexte... C'est bien ça ?

[thelvin]

C'est bien ça. En fait, j'ai mal localisé le problème. J'ai bien un Thread pour une transaction...

Donc il faut bien que j'utilise le ThreadLocal à chaque transaction pour transporter mes données issues du contexte... C'est bien ça ?

Oui, c'est la seule alternative, et c'est en général comme ça que font les outils.

[kikijojo72]

Un grand merci à tous !! Je clos le sujet...