Discussion :

[El Saigneur]

Bonjour

Si je lis la doc Sun JEE : JMS est utilisé pour les communications entre différentes applications.

Mais serait-ce aberrant de faire communiquer une application avec elle-même via JMS pour bénéficier juste des traitements asynchrones qu'offre JMS. Concrètement, je m'explique. J'ai une application qui lance des traitements à l'issu d'une validation de page Web. Le traitement qui est alors lancé est long et on ne peut pas se permettre d'attendre qu'il soit terminé pour rendre la main à l'utilisateur.

Je pensais donc faire ce traitement dans une queue JMS pour le faire de façon asynchrone et rendre la main à l'utilisateur. Qu'en pensez-vous ? Est-ce qu'une simple création de Thread ne ferait pas l'affaire ?

Merci d'avance pour votre aide.

[yannick1717]

Salut,

Je pense que ce n'est pas un mauvais design.

Déjà, c'est plus propre que faire ton thread pool dans un serveur d'application, et en plus tu profites des différents avantages de cette technologie (persistence, monitoring, ...).

Maintenant, si tu n'as besoin vraiment que du traitement asynchrone ou que tu veuilles éviter JMS, tu peux toujours utiliser autre chose. Je sais que, par exemple, Weblogic permet de créer un WorkManager qui est un thread pool, il est mieux de l'utiliser plutôt que de faire son petit pool avec des threads sur lesquels tu perdras peut-être le contrôle.

[El Saigneur]

Merci Yannick pour ta réponse.

Je pense qu'il est effectivement plus propre de partir avec JMS. Mon appli tourne sur JBoss qui fournit une implémentation de JMS. Je vais donc utiliser ça.

A +