Version imprimable
Bonjour,
Aujourd'hui je me retrouve face à un problème. Dans une application serveur en JEE tournant actuellement sous Glassfish ; je vais devoir exécuter des traitements qui pourront durer aux alentours de 5 minutes.
Ainsi, il va falloir que je trouve une solutio car je ne peux pas laisser le client attendre que sa page se charge après 5 secondes... De toute manière, une page d'erreur time out s'affichera bien avant.
Ainsi, comment puis-je t-il procéder?
Merci d'avance.
- utiliser un nouveau thread à partir de ta servlet
- utiliser un ejb session bean asynchrone (il te faut un container compatible ejb 3.1)
Bonjour et merci.
Concernant l'ouverture d'un Thread dans un servlet? N'est-ce pas dangereux?
Ce thread, après un traitement long exécuté par une fonction JNI, devra à la fin mettre à jour un champ dans une base de donnée (pour indiquer le résultat du traitement).
J'utilise les datasources de Glassfish pour faire mes connexion à la base de données. Se servir de cette datasource en dehors du thread principale ne cause pas de soucis?
Concernant le second choix, j'ai vu sur le net que J2EE 3 implémentait les taches asynchrones, mais je n'ai pu réussir à trouver de tutoriels sur le net. Aurais-tu une piste?
Je suis aussi tombé sur l'idée du JMS mais ça me parait trop bien compliquer à mettre en tache pour simplement une seule tache qui se fera en asynchrone.
Tu parles d'EJB 3 plutôt que JavaEE 3 j'imagine
http://javahowto.blogspot.fr/2010/03...in-ejb-31.html
Il n'y a, à priori pas de risque à utiliser un thread à part, pas plus que ton datasource, à partir du moment ou tu traites biens les ouvertures, fermetures de connexions et tes exceptions.
JMS n'est pas si compliqué que cela, mais effectivement un peu plus que les deux autres solutions.
Tout va dépendre de ton serveur d'application et de sa gestion des contexte. Par exemple Websphere, suivant la façon dont tu essaies de récupérer une ressource JNDI depuis le contexte te donnera accès (ou pas) à cette ressource si tu te trouves dans un Thread labellisé JavaEE (donc émis par websphere) ou un thread normal.Citation:
Envoyé par fr1man
Je ne connaissais pas ce genre de limitation.
Dans ce cas, si possible, il vaut mieux passer par un ejb asynchrone, ce qui éviterait le problème que tu cites.
Je rajoute que, si tu as récupéré la datasource dans un thread, il n'est souvent pas possible de l'utiliser dans un autre. Certains conteneurs peuvent, par exemple, systématiquement cloturer toutes les connexion demandées par un thread http en fin de requete http. C'est le cas de jboss qui, au passage, te gratifie d'un gros message dans les logs te faisant comprendre que le programmeur est un gros cochon :mouarf:
Bonjour et merci à tous pour vos réponses.
Pour un début, j'utilise un thread internet au container. Ca a l'air de bien marcher pour le moment mais les tests effectués jusqu'ici ne sont qu'en local et avec un seul utilisateur.
On verra bien si cela posera probleme par la suite dans quel cas je penserai passer par JMS.
Finalement, je vais passer sur des ejb car mon application deviendra distribué dans l'avenir donc autant commencer maintenant.
Jusqu'ici, je faisais tous les appels à la Database dans les servlets. Mais je vois partout qu'il faut mieux les faire dans des EJBs. Pourquoi?
Je commence tout juste à me mettre dans le distribué, ainsi je ne connais pas encore tous les réfléxes à avoir et leur raison d'etre.
Bonjour,
tu as besoin de traitement longs, et tu écris que tu exploites JNI.
Les traitements longs sont généralement traités dans un EJB MDB, activé par message JMS sur une Queue.
JNI, par contre, implique un chargement de librairie native. On tombe alors en dehors des contraintes de sécurité autorisables ( en fonction de la configuration de ton serveur d'application ) pour les composants managés.
Je pense qu'une solution adaptée est de développer un petit connecteur JCA.
Cordialement,
S. Desbois