Salut,
 
Sur http://java.sun.com/j2se/1.4.2/doc [...] ormat.html je lis:

 
Quelqu'un pourrait-il m'en dire plus? Quelles pourraient etre les conséquences? Quelqu'un a-t-il déjà vécu le problème?
 
Merci d'avance

je trouve pas ca pratique, une instance par thread
 
edit:

boah en meme temps ici y'a un imbécile qui a fait un  
public static SimpleDateFormat dateFormat = ...  
alors bon, faut pas s'étonner maintenant
 
(et je m'abstiendrai de nommer l'imbécile sus-mentionné )

http://jakarta.apache.org/commons/ [...] Utils.html
 
attention : le parse de FastDateFormat n'est pas implémenté : seulement le format ...

ben moi je fais du parse, pas d'pot

dommage
 
fait un new à chaque fois, tant pis ... (moi c'est ce que je fais)

ou je synchronise la methode qui utilise le dateFormat.
 
Là je viens d'essayer de produire le problème avec 500 threads, mais ça le fait pas

bon jme demande si j'ai pas merdé dans mes faux threads moi

le coup du sycnhronize moi j'hésiterais ... si c'est un objet "central", ca va te créer un méchant goulot d'étranglement ...

légende urbaine
on parle d'une transaction en base qui locke un objet ou un truc du genre hein, juste un pauvre parse de date... jveux dire créer la nouvelle instance à chaque appel sera probablement au moins aussi couteux... nan?

ben comme je te disais ca dépend. Si c'est une méthode d'un objet qui est fortement solicitée depuis différents threads, ca risque de ralentir globalement ton système.
 
j'ai jamais benché ce genre de truc, mais moi, je préfère limiter au maximum les ressources partagées ... Tant que je peux et que c'est pas trop gourmand en mémoire, chaque thread est indépendant et a ses propres données.

ouais. mtnt que j'y pense c'est l'objet qui a ce DateFormat (et donc la methode que je voulais synchronizer) qui est lui meme threadé. donc suffirait que je vire le static, une instance de mon DateFormat par instance de mon Bidule ça sera bon, et je synchronize la methode des fois que y'aurait plusieurs appels depuis d'autres threads vers mon Bidule.
 

moi je synchronizerais pas dans ce cas, mais j'indiquerais que l'objet n'est pas thread-safe. Un peu comme c'est fait pour SimpleDateFormat, quoi ...

et tu crois que je controle les threads de jboss moi?

bon à part ça si qqun arrive à produire une erreur de parsing en faisant du multi thread avec un SimpleDateFormat partagé entre les threads ça m'interesse parce que moi j'y arrive pas

allez, je réessaie avec 50000 threads

euh ouais ça marcherait ptet mieux si j'appelais Thread.start() au lieu de .run()

probleme reproduit.

on peut meme se manger des NullPointerException

(le getDate() et tout ça c'est parce qu'au début j'avais pas de boucle dans mon thread, je gardais juste un resultat par thread - et le thread etait donc tres court donc bon ça marchait pas trop.. bref )

j'ai pas dit ca ... mais tu devrais savoir si ton objet est partagé entre plusieurs threads ou non, et l'utiliser en fonction ...
 
j'avais cru comprendre que ce n'était pas le cas avec ce que tu avais dit dans le post au dessus ...

   
tu les croyais pas quand il te le disais dans la javadoc ?

bien sur que si mais je voulais voir le genre de problème que ça causait, concretement. (voir premier post du topic )

dans le post au dessus je parlais probablement de mon machin pour reproduire le probleme. mais c'est vrai que je devrais probablement pouvoir savoir si l'objet sera partagé ou pas. cela dit jprefere me mettre à l'abri d'une config foireuse, par exemple

mouais ... moi je préfère que ca se voir quand la config est foireuse ...

j'te dis pas comme ça se voit vachement bien que la config est foireuse quans sans raison apparente t'as une date sur 1000 qui est parsée n'importe comment sans que ça lance la moindre exception

bien sur, je voulais dire le détecter à un autre endroit ...

detecter koi ?

 
le probleme de config je pense

ben c'est ce que j'ai cru deviner, mais si c'est ça euh je vais pas aller taper dans la config de jboss depuis mon code quand meme

 
 
bin merde alors

suis peut etre un imbécile moi mais le jour où t'arriveras à gérer un Thread correctement on en reparlera

 
non masi tu peux detecter si elle convient pas. Apres c'est sur que t'es pas plus avance

je voulais juste dire que c'est souvent une mauvaise idée de prévoir des petits bout de sparadra un peu partout "pour le cas" où un objet serait mal utilisé. Mieux vaut prévenir la mauvaise utilisation ...

Avec un threadlocal tu seras tranquille sans avoir besoin d instancier des  date tout le temps :
 
public class SafeFormat
{
   private static final ThreadLocal local = new ThreadLocal()
   {
      protected synchronized Object initialValue()
      {
         return new SimpleDateFormat();
      }
   };
   public static SimpleDateFormat get()
   {
      return (SimpleDateFormat)local.get();
   }
}
 
Avec ca tu es tranquille, ca va garder un objet SimpleDateFormat par thread et donc tu n auras pas de probleme de concurrence.
 
Pour utiliser c est simple :
 
SimpleDateFormat format = SafeFormat.get();

 
je savais pas à quoi srevait ThreadLocale ... c'est plutot intéressant ... ca ouvre des perspectives ...
je me demande comment c'est géré en interne ...

haaaaan
 
oui c'est interessant, mais dans un contexte j2ee je suis pas sur que ça soit la chose la plus propre à faire

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