Discussion :

[rach375]

Bonjour,

[Deplacé de "struts" vers "Serveurs d'application Java & Java EE"]

J'ai une application qui tourne sous websphère, j'utilise le framework Struts.
Cette application doit lancer plusieurs traitement long et certains doivent s'éxécuter en parralèle.

J'ai donc réfléchi à une solution :

déjà les threads sont déconseillés dans les conteneurs web d'apres la spec J2EE, si j'utilise les threads dans webspheres Est ce que c'est bon puisque c'est un serveur d'application ?

Voici ce que je compte faire :

- mon appli se divise en trois couche,
- les traitements sont tous lancés à travers des threads appelé "unité de traitement" : ceux ci peuvent être lancés en parallèle et sont plus ou moins long
- le séquencement est defini dans une autre classe "sequenceur" qui gérent l'ordonancement des "unités de traitement" : le sequencement est lui meme lancé dans un thread

Tout ces elements se trouve dans la couche application.

Depuis la couche presentation (struts) j'apelle une classe située dans la couche application qui se charge de lancer le thread séquencement. la main est ensuite rapidement retournée à l'utilisateur

le "sequenceur" tourne en tache de fond et lance les "unités de traitment".


Voila comment je compte faire l'appli. je voulais ajourter un point important : dans ce mode, l'application tourne en mode moni utilisateur.

Qu'en pensez vous ?

Merci d'avance

[derek.mf]

Salut,

Personnellement, je dirais que Websphere ou Tomcat, ça ne change en rien le fait que les threads sont déconseillés dans un conteneur Web.

En effet, même si Websphere est un serveur d'application, cela signifie seulement qu'en plus d'un conteneur Web, Websphere met aussi à disposition un conteneur d'EJB. Cela ne change pas le fait que ton appli Web est en train de tourner dans un conteneur Web : celui de Websphere.

Conclusion : Threads déconseillés aussi.

Je rajouterais que, vu ta description du problème, il semblerait que tes longs traitements doivent être exécutés de manière ponctuelle et périodique. Je suppose que tu as une base de données sur laquelle tu dois effectuer de grosses manipulations une fois par jour ou une fois par semaine ou quelque chose comme ça. Dans ce cas, il vaut mieux planifier des traitements de masses (batchs) qui seront planifiés de manière périodique et qui tourneront en dehors du conteneur Web. Bien sur, si mes suppositions sont complètement erronées, oublie ce que je suis en train de dire

@+

[raj]

La norme J2EE déconseille la création de threads en utilisant l'API standard
de J2SE (java.lang.Thread) .
En faite le danger provient de ce tout les threads doivent être géré par le
conteneur .
Par contre Websphere offre un moyen d'utiliser des threads gérés par le
conteneur .
Deux liens intéressant :

http://www-128.ibm.com/developerwork...6_johnson.html

http://gee.cs.oswego.edu/dl/concurre...review_V01.pdf

[woodwai]

J'ai aussi lut pas mal de chose sur le fait que les thread été déconseillé dans une webapp.

Personnelement, j'ai crée pour une grosse société une application de vente en ligne qui utilise une workflow engine pour gérer les commande. Celle-ci tournant bien entendue dans un thread séparé, les command étant géré en paralèle au fonctionnement web de l'application.

Pour des raison de contrainte technique, n'ayant put utiliser un EJB, j'ai été obligé d'utiliser un simple thread. Malgrés que celà soit déconseillé, ça marche trés bien (mon thread est unique par webapps/clone, il est dupliqué dans trois webapp différentes qui sont elle même présent dans 6 clones). Bien sure, les transaction/problèmes de synchronisation on dut être réglé à la main et, si j'avais put utiliser des EJB j'aurais put avoir qu'une seule workflow engine qui fonctionnait. Mais ça fait maintenant 1an et demi que ça fonctionne et on n'a encore perdu aucune commande ...

Donc, pour moi, on peut le faire. Même si ce n'est pas l'idéal.