Discussion :

[piemur2000]

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 :

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

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 :

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

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

[OButterlin]

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

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

[fr1man]

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

[OButterlin]

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

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

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

[piemur2000]

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?

[OButterlin]

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