Discussion :

[Federico_muy_bien]

Bonjour,
je développe une grosse appli Web en JAVA. J'utilise le design pattern des DAO.
Mon problème est que dans ma 1ere couche ou je récupère la request, je récupère l'id de l'utilisateur qui a lancé l'opération mais ensuite dans les couches DTO et DAO je ne sais plus qui a lancé ces actions.

J'aimerai savoir si il y a un moyen de créer une variable "globale" accessible de partout ou mon seul moyen de savoir qui a passé l'action et de passer l'id de l'user à chaque appel de méthode ?

Apache/Tomcat - JAVA7

Merci.
Bonne journée.

[tchize_]

Il n'y a pas de variable globale pour ça. Suivant les frameworks que tu utilise, certaines possibilités te sont offertes. Spring, par exemple, te permettra d'injecter dans ton DAO un donnée qui a un scope request, et qui donc change à chaque requete. JSF te permet d'accédr au FacesContext, mais du coup ton DAO dépend de ton UI. Pas top, mais enrobable dans une classe à part que tu pourra changer le jour ou tu change de vue.

Enfin, en dernier recours, il reste les ThreadLocal, mais c'est vraiment pas évident de les utiliser sans générer des fuites de mémoire

[Federico_muy_bien]

Salut et Merci tchize_.
Le soucis c'est que je n'utilise aucun framework Tout en brut !

Donc pour toi, la "meilleure" solution (par meilleure, j'entends facile, moins risqué et rapide) est de passer ma variable a chaque appel de méthode jusqu'au DAO ?

Tomcat ne peut pas gérer ce genre de choses ?

Merci encore.

[tchize_]

Donc pour toi, la "meilleure" solution (par meilleure, j'entends facile, moins risqué et rapide) est de passer ma variable a chaque appel de méthode jusqu'au DAO ?

Oui, j'ai tendance à dire: si cette donnée est nécessaire au DAO, il faut la lui fournir.

Maintenant, rien ne t'empche non plus d'instancer 1 DAO par requête et de l'initialiser avec tout ce dont il a besoin.

Tomcat ne peut pas gérer ce genre de choses ?

Non, ça ne fait pas partie de ses rôles.

[renoj]

Tu peux implémenter un singleton qui sera chargé de conserver l'id de l'utilisateur qui correspond à chaque thread. Tu appelle une première fois ton singleton pour stocker l'id quand tu es dans ta première couche (servlet ?!).

Tu peux ensuite appeler ton singleton de n'importe où et il te renverra l'id qu'il faut en utilisant Thread.currentThread().getId()

Reste un problème, il faut trouver un moyen de vider ton singleton sinon il va grossir sans cesse.

[Federico_muy_bien]

Tu peux implémenter un singleton qui sera chargé de conserver l'id de l'utilisateur qui correspond à chaque thread. Tu appelle une première fois ton singleton pour stocker l'id quand tu es dans ta première couche (servlet ?!).

Tu peux ensuite appeler ton singleton de n'importe où et il te renverra l'id qu'il faut en utilisant Thread.currentThread().getId()

Reste un problème, il faut trouver un moyen de vider ton singleton sinon il va grossir sans cesse.

PARFAIT !
Ça marche impec cette solution !!
Merci !

[tchize_]

Tu peux implémenter un singleton qui sera chargé de conserver l'id de l'utilisateur qui correspond à chaque thread. Tu appelle une première fois ton singleton pour stocker l'id quand tu es dans ta première couche (servlet ?!).

Tu peux ensuite appeler ton singleton de n'importe où et il te renverra l'id qu'il faut en utilisant Thread.currentThread().getId()

Reste un problème, il faut trouver un moyen de vider ton singleton sinon il va grossir sans cesse.

Bref exactement ce que fait ThreadLocal en beaucoup moins performant mais avec la même problématique du netoyage

[Federico_muy_bien]

Oui c'est vrai. Mais en fait c'est moins pénible à mettre en place que le passage de variable (surtout après avoir commencé a coder). Merci.

[renoj]

Bref exactement ce que fait ThreadLocal en beaucoup moins performant mais avec la même problématique du netoyage

Effectivement j'ai réinventé la roue !