Pourquoi les threads spawning dans le conteneur Java EE sont-ils déconseillés?

Question

L'une des premières choses que j'ai apprises au sujet du développement de Java EE est que je ne devrais pas générer mes propres threads dans un conteneur Java EE. Mais quand j'y pense, je ne connais pas la raison.

Pouvez-vous expliquer clairement pourquoi il est découragé?

Je suis sûr que la plupart des applications d'entreprise ont besoin d'une sorte d'emplois asynchrones comme daemons de messagerie, les sessions inactives, les travaux de nettoyage, etc.

Ainsi, si en effet on ne doit pas engendrer des fils, ce qui est la bonne façon de le faire si nécessaire?

Answer 1

Il est déconseillé car toutes les ressources de l'environnement sont censées être gérées, et potentiellement surveillées, par le serveur. En outre, une grande partie du contexte dans lequel un thread est utilisé est généralement attaché au thread d'exécution lui-même. Si vous lancez simplement votre propre thread (ce que je crois que certains serveurs ne permettent même pas), il ne peut pas accéder à d'autres ressources. Cela signifie que vous ne pouvez pas obtenir de requêtes InitialContext et JNDI pour accéder à d'autres ressources système telles que les fabriques de connexions JMS et les sources de données.

Il existe des moyens de le faire "correctement", mais cela dépend de la plate-forme utilisée.

The commonj WorkManager is common for WebSphere and WebLogic as well as others

More info here

And here

également fait double emploi avec un peu this one ce matin

MISE À JOUR: S'il vous plaît noter que cette question et la réponse se rapportent à l'état de Java EE en 2009, les choses ont amélioré depuis lors!

Answer 2

Je n'ai jamais lu que c'est découragé, sauf du fait que ce n'est pas facile à faire correctement.

Il s'agit d'une programmation de bas niveau, et comme d'autres techniques de bas niveau, vous devriez avoir une bonne raison. La plupart des problèmes de concurrence peuvent être résolus beaucoup plus efficacement en utilisant des constructions intégrées comme des pools de threads.

Answer 3

La raison pour laquelle vous ne devez pas générer vos propres threads est que ceux-ci ne seront pas gérés par le conteneur. Le conteneur prend soin de beaucoup de choses qu'un développeur novice peut trouver difficile à imaginer. Par exemple, des choses comme le regroupement de threads, la mise en cluster, les récupérations après incident sont effectuées par le conteneur. Lorsque vous démarrez un thread, vous risquez de perdre certains d'entre eux. Le conteneur vous permet également de redémarrer votre application sans affecter la JVM sur laquelle il est exécuté. Comment cela serait-il possible s'il y avait des threads hors du contrôle du conteneur?

C'est la raison pour laquelle les services de minuterie J2EE 1.4 ont été introduits. Voir article this pour plus de détails.

Answer 4

Il n'y a pas de véritable raison de ne pas le faire. J'ai utilisé Quarz avec Spring dans une webapp sans problèmes. Le cadre de concurrence simultanée java.util.concurrent peut également être utilisé. Si vous implémentez votre propre gestion de thread, définissez les theads sur deamon ou utilisez un groupe de threads deamon pour eux afin que le conteneur puisse décharger votre application Web à tout moment.

Mais attention, les champs d'application de haricots session de et demande ne fonctionnent pas dans les discussions donné naissance!Également un autre code publié sur ThreadLocal ne fonctionne pas de la boîte, vous devez transférer les valeurs aux threads générés par vous-même.

Answer 5

Vous pouvez toujours demander au conteneur de démarrer des éléments dans le cadre de vos descripteurs de déploiement. Ceux-ci peuvent alors faire toutes les tâches de maintenance que vous devez faire.

Suivez les règles. Vous serez heureux un jour que vous l'avez fait :)

Answer 6

Une raison que j'ai trouvée si vous avez engendré des threads dans votre EJB et que vous essayez de faire décharger ou mettre à jour votre EJB, vous allez rencontrer des problèmes. Il y a presque toujours une autre façon de faire quelque chose où vous n'avez pas besoin d'un fil, alors dites simplement NON.

Answer 7

Pour EJBs, il est non seulement découragée, il est expressément interdit par le specification:

Un haricot d'entreprise ne doit pas utiliser les primitives de synchronisation fil à synchroniser l'exécution de plusieurs instances .

et

Le haricot de l'entreprise ne doit pas tenter de gérer threads. Le bean entreprise ne doit pas tenter de démarrer, arrêter, suspendre ou reprendre un fil, ou changer la priorité ou le nom d'un fil. Le bean enterprise ne doit pas tenter de gérer les groupes de threads.

La raison en est que les EJB sont destinés à fonctionner dans un environnement distribué. Un EJB peut être déplacé d'une machine dans un cluster à un autre. Les threads (et les sockets et autres équipements restreints) constituent un obstacle important à cette portabilité.

Answer 8

Les fils sont interdits dans les conteneurs Java EE conformément aux plans. Veuillez vous référer au blueprints pour plus d'informations.

Answer 9

Concurrency Utilities pour Java EE

Il y a maintenant une norme et bonne façon de créer des threads avec le noyau API Java EE:

• JSR 236: Concurrency Utilities for Java™ EE

En utilisant Concurrency Utils, vous vous assurez que votre nouveau thread est créé et géré par le conteneur, garantissant que tous les services EE sont disponibles.

Exemples here