Objet unique par session dans un contexte métier

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:

---

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:

---

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... :ccool:

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

Citation:

---

Envoyé par kikijojo72

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

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 ?

Citation:

---

Envoyé par kikijojo72

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

Citation:

---

Envoyé par kikijojo72

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)

Citation:

---

Envoyé par -gma-

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 ?

Citation:

---

Envoyé par kikijojo72

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.

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