Discussion :

[mrjeronimo]

Bonjour,

Sauriez vous me dire si les singeltons crées via Spring sont multi thread.

Par exemple, un Singeton assurant des opérations de création et modification sur une source de données est-il capable de lancer ces traitements dans des threads différents ?
Je m'explik encore : si deux reqûets demandent à ce singeltin d'opérer une modif, comment gérera-t-il leur demandes simultannées?

Merci d'avance pr votre aide

[djo.mos]

Bonjour,
Ca ne dépend aucunement de Spring mais plutôt de celui qui a codé le bean (qui doit s'assurer ques ss méthodes sont thread-safe).
C'est tout comme pour les servlets par exemple.

[julien.dubois]

Quitte à répéter djo.mos :
Assurez-vous bien de faire des beans thread-safe!! C'est la principale erreur que je vois dans les applications Spring, c'est pourquoi je me permets d'insister.

Les Servlets fonctionnent effectivement de la même manière, ainsi que les actions Struts : c'est en effet la meilleure façon d'avoir des applications performantes, car on crée ainsi un minimum d'objets.

Une manière simple de s'assurer que vos beans sont thread-safe : vous ne devez pas avoir de variable de classe. Déclarez toutes vos variables à l'intérieur de vos méthodes et vous serez tranquilles.

[mrjeronimo]

Merci pour vos reponses.

Je prends bien le soin de préciser d'une part à Spring qu'il doit créer des singeletons et d'autres de n'utiliser aucune variable d'instance, à moins qu'elle soit elle aussi un singleton, c'est le cas par exemple pour mon bean métier qui appelle mon bean DAO.

Je crois que la reponse à ma question est que que c'est au développeur de gérer le multi threading de ses méthodes (en y ajoutant par exemple le mot clé "synchronised"). Si je dis du n'importe quoi merci de me le réctifier

[julien.dubois]

Je ne suis pas vraiment d'accord : si vous avez deux threads qui accèdent en même temps à une méthode d'un singleton thread-safe, cela ne posera aucun problème. Les deux pourront s'exécuter en parallèle.
Si vous mettez le mot-clef synchronized vous allez forcer ces deux threads à s'exécuter l'une après l'autre, ce qui va vous faire un goulet d'étranglement assez monstrueux.
Si votre singleton est thread-safe cela ne sert à rien...
Et si pour une raison quelconque vous ne pouvez pas faire d'objet thread-safe, Spring vous propose (entre autres) le scope "prototype", qui fera que vos beans ne seront plus des singletons.

[djo.mos]

Oui, c'est ça l'idée.
Seulement, le synchronized est vraiment à manier avec la plus grande prudence. C'est tu marques toutes les méthodes de ton bean en tant que synchronized, tu tues carrément le multithreading, dans la mesure ou toutes les threads accédant à tes beans vont devoir se servir en une file, l'une après l'autre.

Imagines ce qui se passera avec un DAO ou un service avec 10 ou 20 utilisateurs en parallèle ...

Je ne dis pas non plus qu'il ne faut jamais utiliser synchronized, mais il faut vraiment choisir avec soin quoi mettre en synchronized (pas toute une méthode quand même) et quand l'utiliser.

Après, si tu codes tes beans dans une approche stateless (comme dans un langage fonctionnel), alors t'es sûr que tu seras tranquil : pour ce faire, c'est simple (et c'est dit par Julien Dubois): ne pas utiliser des champs d'instance. travaille seulement sur les paramètres que tu reçois et sur des variables locales.

Exemple:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
@Service
@Transactional
@Scope("singleton")
class MonServiceQuiVaCapoterEnMultithread{
  @Resource
  private MonDao dao;
 
  private List<Person> persons;
 
  public void unTraitementQuiVaCapoter(String filtre){
     persons = dao.filter(filtre); //(1)
     for(Person p : persons){ //(2)
        FaireUnTruc; //(3)
     }
  }
}

Là, on utilise un champ d'instance (persons) dans une méthode.
imagine le cas suivant:
- Utilisateur U1 invoque ce service dans un thread T1 avec comme paramètre "%a%";
- Et Utilisateur 2 de même invoque ce service, mais dans un autre thread T2 et en utilisant le paramètre "%b%";

Rien n'empêche que ça se déroule ainsi (contrôlé par l'ordonnanceur):
Thread | instruction
T1 | (1)
T1 | (2)
T2 | (1)
T1 | (3)
T2 | (2)
T1 | (3)
T2 | (3)
T1 | (3)

Bref, en gros, le thread T1 charge la liste des personnes avec a dans leur nom dans le champ persons et commence à intérer ladessus.
Entre temps, T2 ecrase ce champ avec la liste des personnes avec un b dans leur nom.

Je te laisse imaginer le désarroi du pauvre thread T1 quand la liste change en cours d'itération

Or il aurait suffit d'utiliser une variable locale pour que tout ça soit évité.

[mrjeronimo]

Je ne suis pas vraiment d'accord : si vous avez deux threads qui accèdent en même temps à une méthode d'un singleton thread-safe, cela ne posera aucun problème. Les deux pourront s'exécuter en parallèle.

C'est effectivement mon cas, j'ai des actions Struts 2 qui accèdent sur des threads différents vers un singleton qui se charge d'effectuer des méthodes d'accès à la BD.

Donc si j'ai bien compris, tous mes threads utiliseront l'instance unique de mon singleton, mais exécuteront les méthodes de celui là autant de fois que nécessaire. Toutefois, je ne conçois pas comment est-il possible de ne disposer que d'une seule instance et de pouvoir utiliser plusieurs fois ses méthodes

Merci bcp d'avance!

[djo.mos]

Ca, ça n'a plus aucun lien avec Spring ni Struts : c'est la notion du multi-threading.

Je te conseille vivement de consulter quelques cours ladessus comme ici par exemple.

[mrjeronimo]

merci bcp pr ton aide !