Threads in Spring

Question

Je possède une application Web utilisant Spring et Hibernate et Struts (qui s'exécute sur Tomcat)

La séquence d'appel est quelque chose de ce genre...

L'action Struts appelle un bean de service Spring qui à son tour appelle un bean DAO Spring. L'implémentation DAO est une implémentation Hibernate.

La question est Est-ce que tous mes beans Spring s'exécuteront dans le même thread ? Puis-je stocker quelque chose dans le ThreadLocal et le récupérer dans un autre bean?

Je suis assez sûr que cela ne fonctionnerait pas dans les EJB à session sans état. Le conteneur EJB peut (ou va) créer un nouveau thread pour chaque appel au bean de session

Le conteneur Spring fera-t-il la même chose? c'est-à-dire exécuter tous les beans dans le même thread ?

Lorsque j'ai essayé un test JUnit - j'ai obtenu le même identifiant via Thread.currentThread().getId() dans le cas de test et les deux beans - ce qui me conduit à croire qu'il n'y avait qu'un seul thread en action

Ou le comportement est-il imprévisible? Ou changera-t-il lors de l'exécution sur le serveur Tomcat ?

Clarification Je ne souhaite pas échanger des données entre deux threads. Je veux mettre des données dans le ThreadLocal et pouvoir les récupérer de tous les beans dans la pile d'appels. Cela ne fonctionnera que si tous les beans sont dans le même thread

Answer 1

Spring ne crée pas les threads. Tomcat le fait. Spring se contente de créer et de connecter les objets pour vous.

Chaque demande du navigateur est traitée dans une seule demande. C'est Tomcat qui gère la demande. C'est Tomcat qui crée le thread pour traiter la demande.

En supposant que vous venez de créer un bean singleton dans Spring appelé "X". Alors la même instance de X est utilisée par toutes les demandes.

Les beans Spring ne vivent pas dans un thread. Ils sont simplement alloués sur le tas.

Answer 2

Est-ce que tous mes beans de printemps s'exécutent dans le même fil ? Puis-je stocker quelque chose dans le ThreadLocal et obtenir le dans un autre bean ? À ma connaissance, pour les composants que vous avez mentionnés (service bean, DAO bean - je suppose qu'il s'agit de simples beans spring), Spring ne crée pas un nouveau thread. Je ne comprends pas votre cas d'utilisation (c'est-à-dire, échanger des données entre deux threads).

Pour la plupart des applications web, un nouveau thread est créé pour chaque nouvelle requête, et si vous voulez partager des données entre deux requêtes, vous utilisez normalement : - les paramètres get/post pour passer les données - la session pour partager les données

Pour répondre à votre question, je suis assez sûr que le conteneur spring ne crée pas de threads pour la plupart des composants.

Answer 3

Oui, vous pouvez le faire. Le même thread sera utilisé pour exécuter votre action donc le ThreadLocal fonctionnera. En général, le même thread est utilisé pour le bean de session sans état également, en supposant qu'il soit en cours d'exécution dans la même instance du serveur d'application. Je ne compterais pas là-dessus cependant, car cela dépend probablement du fournisseur.

Nous utilisons cette technique pour accéder à l'identité des appelants n'importe où dans le code. Nous utilisons également des beans de session et jms, mais passons explicitement les informations entre les conteneurs et définissons le ThreadLocal à chaque point d'entrée. De cette façon, cela n'a pas d'importance si le bean (session ou mdb) est local ou non.

Answer 4

En plus de toutes les autres réponses, je vais simplement ajouter ce qui suit :

Normalement, la seule raison de changer de threads est en raison d'une exigence de parallélisme. Comme cela n'arrive généralement pas gratuitement en termes de complexité, vous serez généralement clairement informé lorsque cela se produit.

Changer de threads dans ce qui semble être un traitement mono-thread d'une requête est en fait extrêmement complexe. Cela se produira normalement seulement à un endroit dans un conteneur, et c'est généralement géré par les lecteurs de socket tcp/ip qui reçoivent la requête des clients externes. Ces threads lecteurs déterminent généralement quel thread (pool) doit traiter la requête et transmettent la requête à ce thread. Ensuite, la requête reste avec ce thread.

Donc normalement, la seule chose qui se passera/can se passera est que des threads supplémentaires seront créés pour le parallélisme ou le traitement asynchrone (comme JMS).