Threads et Java EE

Bonjour,

J'ai un problème avec mon application Java EE déployée sur un serveur glassfish 3.0.1. Le but de l'application est d'executer différentes actions regroupées en liste dans des entités.

En gros j'ai un EntityBean entite qui contien une liste d'actions :

Code:

---

1 2 3 4 5 6 7

@Entity public class Entite implements Serializable { ... @OneToMany(mappedBy="entite", cascade = CascadeType.ALL) private List<Action> actionList = new ArrayList<Action>(); ... }

---

Pour pouvoir exécuter les actions de plusieurs entités en même temps je démarre un thread pour chaque liste d'action à exécuter:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

@Override public void run() {   for (Action action : entite.getActionList()) { // exécution de l'action...   // Wait the needed time after action execution. try { Thread.sleep(action.getWaitDelay() * 1000); } catch (InterruptedException ex) { logger.log(Level.SEVERE, null, ex); } }   // Callback pour notifier le session bean de la fin de l'execution. entiteSessionBean.entiteExecuted(entite);   }

---

Les threads sont lancés par un Stateless session bean qui est notifié a la fin de l'exécution des actions de chaque entité. A ce moment la il "persist" l'entité pour modifier sont état à "exécutée".

Lorsque j'exécute les actions de plusieurs entités à la fois mon application deviens instable et ne réponds plus aux requêtes du front.

Est-ce que ma démarche vous semble correcte?
Est que l'exécution de plusieurs threads accedant à des entity beans et a un session beans est une chose qui se fait bien en Java EE?
Avez-vous une piste qui pourrait me mettre sur la voie de mon problème?

Si tu veux faire de l'asynchrone, il te faut regarder du côté des message driven bean.

Il est déconseillé d'utiliser des threads dans une application J2EE.

Citation:

---

Envoyé par fr1man

Il est déconseillé d'utiliser des threads dans une application J2EE.

---

Plutôt dans les EJB... JEE, c'est vaste...

Oui, mais je pensais également aux servlets, jsp etc...

Citation:

---

Envoyé par fr1man

Oui, mais je pensais également aux servlets, jsp etc...

---

Mauvais exemples... les servlets (et donc les jsp) sont multi-thread ;)

Ce n'est pas du tout ce que je dis.
Je dis qu'il n'est pas conseillé d'utiliser de nouveaux threads pour effectuer des tâches asynchrones. On a plus aucun moyen de gérer les montés en charges à partir du serveur d'application, d'où l'utilisation de MDB.

Citation:

---

Envoyé par fr1man

Si tu veux faire de l'asynchrone, il te faut regarder du côté des message driven bean.

Il est déconseillé d'utiliser des threads dans une application J2EE.

---

Merci pour l'information, je vais banir les threads de mon application.

Je viens de trouver l'interface WorkManager qui semble être une alternative aux MDB. Qu'en pensez vous? Connaissez vous un moyen d'utiliser cette interface avec Glassfish?

Citation:

---

Envoyé par fr1man

Ce n'est pas du tout ce que je dis.
Je dis qu'il n'est pas conseillé d'utiliser de nouveaux threads pour effectuer des tâches asynchrones. On a plus aucun moyen de gérer les montés en charges à partir du serveur d'application, d'où l'utilisation de MDB.

---

Ben j'avais pas bien interprété "Il est déconseillé d'utiliser des threads dans une application J2EE"... tu avoueras que ce n'était pas bien précis...;)

Citation:

---

Envoyé par piemur2000

Merci pour l'information, je vais banir les threads de mon application.

Je viens de trouver l'interface WorkManager qui semble être une alternative aux MDB. Qu'en pensez vous? Connaissez vous un moyen d'utiliser cette interface avec Glassfish?

---

Si tu cherches à exécuter des actions de manière asynchrone et/ou planifiées, tu peux également utiliser Quartz.

Ceci dit, si l'aspect performance est important, je te suggère tout de même les MDB... comme le propose fr1man...

Certes ce n'était pas très précis.

J'ai peut-être été également un peu extrémiste dans le sens où, rien interdit de créer des threads dans une servlet. Là, c'est plus une conviction personnelle.
La spec JEE déconseille cela surtout pour les ejbs comme la dit OButterlin.

de toutes facons, beaucoup de choses (comme la transaction, les permissions en cours etc) sont liées au thread courant, le nouveau thread n'en héritera pas nécessairement.

et +1, laisser le conteneur, dans la mesure du possible, gérer lui même les threads ;)

Je me sers pas mal des Thread quand je dois contacter plusieurs serveurs (application de supervision).
Ca me permet de paralléliser les audit qui peuvent durer plusieurs secondes par serveurs (passer de 30 secondes à 5 secondes, c'est toujours bon à prendre).
Bon c'est de l'intranet j'ai pas trop de problème de montée en charge, ça serait peut-être différent avec un site plus sollicité...

pour ce genre de cas, une page, de l'ajax, et ce sont desthread HTTP que tu utiliser, le client a tout de suite une réponse (et pas au bout de 5 seconde) avec des barres ou des témons "en attente" ;)



Comme pour tout de toutes façons, il y a les recommandations théoriques et la pratique

Citation:

---

Envoyé par tchize_

pour ce genre de cas, une page, de l'ajax, et ce sont desthread HTTP que tu utiliser, le client a tout de suite une réponse (et pas au bout de 5 seconde) avec des barres ou des témons "en attente" ;)



Comme pour tout de toutes façons, il y a les recommandations théoriques et la pratique

---

C'est pas faux tiens j'avais pas pensé à Ajax... ben j'y réfléchirai ;)

Puisque c'est du GlassFish 3.0.1 et donc que Java EE 6 est dispo, il y a les EJB 3.1 Asynchrones (sans besoin de JMS) et l'annotation @Schedule qui remplacera avantageusement bon nombre de cas d'usage Quartz.

Merci pour vos réponse.

J'ai donc utilisé des Message Driven Beans pour résoudre mon problème. Je reste cependant perplexe. En effet deux cas se présentent dans mon application. Le premier est celui que je vous ait expliqué :
1. J'ai une liste d'action à exécuter, un timer bean récupère la liste des actions et les transmet à un MDB. Tout se passe bien.
Le deuxième est légèrement différent :
2. Je dois mettre à jour une liste d'Entity Bean. Je j'utilise le même mécanisme que pour le point 1. j'ai de gros problèmes de synchronisation. En gros tous les Entity Beans mis a jour par le MDB ne sont pas a jour dans le reste de l'application. Par contre si j'utilise un thread pool au lieu d'un MDB, tout se passe bien.

Pourquoi est ce que j'ai des problèmes de synchronisation lors de l'utilisation de MDB? Est ce que je dois faire quelque chose de particulier pour prévenir l'entity manager que l'Entity Bean à été mis a jour? J'ai essayé de faire un refresh sans succès.