Reprise du message précédent :

il n'y a pas de honte à ne pas savoir, il n'y a que honte à ne pas apprendre
 
je savais que ca permettait ce genre de truc, mais je pensais pas que c'était comme ca que ca s'utilisait ... c'est assez spécial...
Faudra que je me lise de la doc là dessus ...

j'ai jamais de multi thread

 
en fait c est une bete Map thread->object :
 
j imagine que le get est implemente commce ceci :
 
public Object get()
{
   return map.get(Thread.currentThread());
}

Aucun danger c est safe vu que tu utilises ton ThreadLocal a toi.
 
Lors de l undeploy de l application, ta classe passe au garbage et le ThreadLocal avec.
 
Mais bon j admet que l utilisation de ThreadLocal releve souvent du hack :-)
 

 
si si, ça change rien. Fin si ton appli n'est pas en clustering, c'est bon.

qu'est-ce qui change rien? et je vois pas le rapport avec le clustering.
 
je disais juste que j'allais pas commencer a jouer avec ThreadLocal dans un session bean pour faire *ça* alors que je pouvais betement garder une instance par sb et faire gaffe à ce que je fais ou bien réinstancier le bidule à chaque fois et basta.

nan en fait, c'est encore plus con que ca : y a une Map "package protected" dans le Thread => le ThreadLocale s'enregistre directement dans cette Map.

c'est calir que ca fait un peu con de "surcharger" un Thread d'un environnement J2ee pour ca ... si tout le monde fait ca, il va devenir chargé le thread

En fait, c est un HashMap donc ca ne va rien surcharger du tout vu que l acces est en constant O(1).
 
Au niveau du garbage, les entries dans la Map utilisent des weak references, donc des que l objet ThreadLocal passe au garbage, la map maintenue au niveau du thread est nettoyee.
 
C est sur que si l on traite toutes les dates au meme endroit il est inutile d utiliser ce genre de hack. Maintenant si on manipule les dates dans pleins de classes differents, cela peut etre interessant d utiliser cela.
 
La ou ca peut etre interessant est en terme d'utilisation d objets, car c est imbatable : le nombre de SimpleDateFormat crees est egal au plus au nombre de thread tournant dans la VM.
 

c'est calir que ca fait un peu con de "surcharger" un Thread d'un environnement J2ee pour ca ... si tout le monde fait ca, il va devenir chargé le thread

je voulais juste dire que si chaque classe fait ce genre de truc dans son coin, le thread allait se trainer bcp d'objet => grosse consomation mémoire ... et surtout non garbage collecte (enfin tant que le threadloclae est référencé ...

En fait, ces objets la si tu ne les met pas dans le thread, tu les mettras ailleurs ca reviendra au meme. Maintenant si tu as besoin d'un objet SimpleDate a un moment precis c est sur que ca ne vaut pas le coup.
 
 

on est d'accord. Ce que je veux dire c'est qu'une fois qu'ils sont dans le thread, ils y sont généralement pour un moment dans un Context J2EE (dans lequel les ejb sont cachés et les threads poolés)

Je suppose que la remarque à propos du clustering de darque était la suivante : si le bean migre d'une JVM à une autre, le ThreadLocal va pas le suivre, donc ça va mal se passer.

 
tout à fait

Je suis le |-|4><0R du JZ33

je vois pas bien ce que ca change ... un autre ThreadLocale sera créé et puis voilà ...

c'est sûr que dans le cas présent, on s'en fout, mais dans le cas général, ça va très mal se passer si un ejb a un de ses membres qui changent à la volée.

 
et l'information contextuelle elle passe avec? Ct une discussion plus générale que le SimpleDateFormat

ca me viendrait pas trop à l'idée de mettre des infos contextuelles dans un thread, mais tu as raison ... on peut pas l'empecher ...
 
quelle genre de données contextuelle tu voudrais mettre ? t'as un exemple ?

 
J'ai un exemple pratique. J'ai un framework batch utilisé pour lancer des taches lourdes en asynchrone. Le batch se fait en plusieurs étapes distinctes et je souhaite passer une information contextuelle pendant son exécution. Au lieu de passer un objet "Contexte" à chacune de mes méthodes, je la stocke (et le cache -> protected) dans un ThreadLocal.  
 
Cela dit, je vais devoir changer ça puisqu'on est justement en train de clusteriser le truc
 
Cela dit ca a du sens car le traitement du batch est initié par une message recu sur une queue JMS (un thread, démarré lorsqu'un message d'éxécution de batch est recu)

à l'intuite, je dirais qu'on peut faire un traitement de 3 heure dans un bean JMS puisque le container a le droit de le dupliquer pour libérer le thread.
 
J'ai faux ?  
 
 
Je hacke trop ?

les objets SimpleDate sont stateless donc cela n influe pas dans ce cas la.
 

 
oui un thread local ne remplace pas une session, ce n est pas un endroit pour y ranger des objets propres a un utilisateur mais propre a un thread, security, transaction etc...
 
Si l on veut y mettre de l info propre a un user, il faut dans ce cas utiliser une methode du genre ServletFilter :
 
public void doFilter(req,resp)
{
   try {
      Object o = getSomeUserSessionObject();
      Storage.set(o);
      doFilter(req,resp);
      }
   finally {
      Storage.set(null);
      }
 
Et ensuite dans le reste de la stack j2ee on peut utiliser l objet de session. Certains font ca dans leur appli web, c est tout a fait valide mais cela montre des defaut dans le design de leur appli a moon avis.
   
}
 
------
 
Pour en revenir a ce qui confirmait Darklord, avec l exemple ci dessus, l objet va etre desassocie du Thread qd la requete se termine et ensuite la replication de la session HTTP repliquera l'etat de l'objet sur le cluster.

pour pinailler un peu : y'a des setBidules() dans SimpleDateFormat donc ils sont pas du tout stateless.
 
pour être plus sérieux, bientendu que dans ce cas-là, on peut migrer sans pb, mais le but était d'ouvrir le débat. C'est une technique loin d'être généralisable et complètement hors-spec.

là c'est même très con ... autant stocker l'objet en attribut de requete ...
 
edit : à moins que tu ais pas accès à la requête dans les objets dans lequels tu veux utiliser cet objet

comment ca s'utilise habituellement un ThreadLocal depuis plusieurs objets différents ? on stocke l'instance du ThreadLocale en tant que variable static pour pouvoir y accéder depuis tous les objets ?

oui, je suppose. mais je suppose surtout qu'habituellement ça ne s'utilise pas ...

bha pkoi pas ? le coup de la simpledateformat ce serait stupide de limiter son utlisation à un seul objet ...

En general tu ne te sers du ThreadLocal que temporairement durant une invocation. Par exemple dans le cas d'un EJB appelant un autre EJB dans un autre VM par un mecanisme de transport comme RMI, tu as ce genre de chose pour propager le role de securite par exemple :
 
Servlet -> Stateless EJB qui donne le role "user" -> EJBDistant.blah() Appel RPC dans un autre container -> blah() -> etc....
 
Le stateless associe le role "user" avant d entrer dans la methode business du stateless. Ce role "user" est attache a l'appel par un ThreadLocal. Ensuite la method business appelle l EJB distant via son proxy et a ce moment la le role "user" attache au ThreadLocal est passe dans l'appel distant. Lorsque l EJB distant recoit l appel, il prend ce role "user" et le reassocie au thread grace au ThreadLocal.
 

lol, ok.
 
Quand je dis stateless c est dans le contexte d utilisation court que dure un SimpleDateFormat i.e :
 
a = new SimpleDateFormat();
// on utilise a
a = null; // le garbage va recuperer a
 

 
tout a fait.

et ca se passe comment le user à l'EJB distant ? c'est quoi l'intérêt de la passer dans un ThreadLocale plutot que directement ?

http://www-106.ibm.com/developerwo [...] hreadlocal
http://www.javaworld.com/javaworld [...] 6-dcl.html
 
pas très locace google sur ce coup ...

benou > je spécule que c'est parce que un seul thread peut rentrer à la fois dans un bean et qu'on laisse la concurrence entre threads se démerder jusqu'à l'entrée dans le bloc de synchronisation (dans le proxy d'ejb) donc on doit avoir un code uniforme (ie. on s'en branle du thread, on va chercher l'user et c'est le bon, à tous les coups).

 
Dans ce cas la tu n a pas le choix car tu appelle du code utilisateur. Supposons que le code du container EJB appelle la methode du stateless bean :
 
Principal principal = getPrincipalForThisEJB();
SecurityAssociation.setPrincipal(principal);
stateless.methode(); // En general c est un appel reflectif
 
-----------
 
dans ma methode de l'EJB tu as :
 
public void methode()
{
   distant.methodeDistante();
}
 
-----------
 
En fait distant est un proxy qui va faire qqch du genre :
 
Principal principal = SecurityAssociation.getPrincipal();
Invocation invocation = new Invocation();
invocation.setPrincipal(principal);
invoker.invoke(invocation);
 
-----------
 
L'objet invocation represente une invocation et l'objet invoker represente un mechanisme de transport qui va envoyer l objet invocation ailleurs.
 
Dans ce cas la on voir que l info dans le ThreadLocal va etre utilisee pour etre ensuite attachee a l'invocation.
 
-----------
 
Au final le conteneur EJB **DOIT** utiliser l objet ThreadLocal pour parvenir a ses fins.

ha ok, tu parlais du code du conteneur EJB ... je croyais que du codage des ejb en eux même ...

 
C'est un exemple pour montrer que l info dans le TheadLocal n'y reste pas tout le temps, en general que durant le temps d'une invocation.

ok j'ai capté

une question bête : pkoi ils ont pas plutot rendu accessible une Map au niveau du thread (genre Thread.getAttributeMap()).  
Pkoi ils se sont fait chier à faire ThreadLocal ?