Comment un EJB paralléliser une longue, l'UC?
L'application dispose d'un CPU intensive long processus qui se déroule actuellement sur un serveur (un EJB méthode) en série lorsque le client le demande.
C'est théoriquement possible (d'un point de vue conceptuel) pour diviser le processus en N morceaux et de les exécuter en parallèle, aussi longtemps que la sortie de tous les emplois parallèles peuvent être recueillis et réunis avant de l'envoyer au client qui a initié le processus. Je voudrais utiliser cette parallélisation pour optimiser les performances.
Comment puis-je mettre en œuvre cette mise en parallèle avec les Ejb? Je sais que nous ne devrions pas créer des threads dans un EJB de la méthode. Au lieu de cela, nous devrions publier des messages (un par poste de travail) pour être consommés par les message driven beans (Bmd). Mais alors il ne serait pas un appel synchrone plus. Et d'être synchrone semble être une exigence dans ce cas car j'ai besoin de recueillir la sortie de tous les emplois avant de l'envoyer au client.
Est-il une solution pour cela?
OriginalL'auteur b.roth | 2010-01-05
Vous devez vous connecter pour publier un commentaire.
Cette question a été soulevée à plusieurs reprises, et je vais résumer qu'il y a plusieurs solutions possibles, dont 1 seul je le recommande.
Utiliser un WorkManager de la commonj API. Il permet à la gestion des threads dans un conteneur Java EE et est spécifiquement conçu pour s'adapter à votre cas d'utilisation. Si vous êtes à l'aide de WebSphere ou WebLogic, ces API sont déjà disponibles sur votre serveur. Pour les autres, vous devez mettre un tiers solution en vous-même.
WorkManager info
Questions connexes
Pourquoi Frai fils est découragé
WorkManager
est WebSphere spécifique, donc impropres à l'alimentation en général: stackoverflow.com/questions/9026516/...Qui ne se réfère pas à la commonj WorkManager, mais un IBM specifig solution antérieure. Comme je l'ai déjà mentionné déjà commonj n'est pas IBM spécifique et est disponible dans la plupart des plates-formes.
OriginalL'auteur Robin
Il y a toutes sortes de façons de le faire.
Vous pouvez utiliser un EJB de la Minuterie pour créer une course-une fois le processus qui va commencer immédiatement. C'est une bonne technique pour appeler des processus en arrière-plan. Un EJB Timer est associé à une Session Bean mise en œuvre. Vous pouvez ajouter un EJB Minuterie pour chaque Session Bean que vous voulez être en mesure de le faire, ou vous pouvez avoir une seule Session Bean qui peut ensuite appeler la logique de l'application par le biais de certains d'expédition mécanisme.
Pour moi, je passe un serializable blob de paramètres avec un nom de classe qui répond à une interface spécifique à un générique Session Bean qui exécute alors la classe. De cette façon, je peux facilement le fond plus rien.
Une mise en garde à propos de l'EJB de la Minuterie est que EJB Minuteries sont persistantes. Une fois que vous créer un EJB de la Minuterie est reste dans le récipient jusqu'à ce que son travail est terminé ou annulé. Gotcha sur c'est que si vous avez un long processus en cours d'exécution, et le serveur tombe en panne, lorsqu'il redémarre le processus va se poursuivre et de reprendre. L'esprit, cela peut être une bonne chose, mais seulement si votre processus est prêt à être redémarré. Mais si vous avez un simple processus d'itération sur les "10 000", si le serveur tombe en panne sur l'élément à 9 999, quand il s'agit de sauvegarder, vous pouvez facilement voir tout simplement de recommencer au point 1. Tout est réalisable, juste une mise en garde d'être au courant de.
Une autre façon de fond quelque chose est que vous pouvez utiliser une file d'attente JMS. Mettre un message sur la file d'attente, et le gestionnaire s'exécute aysnchronously du reste de votre application.
L'astuce ici, et quelque chose que j'ai a également fait misant sur le travail avec la Minuterie de Haricots, vous pouvez contrôler la façon dont de nombreux "emplois" se lancer en fonction du nombre de MDB cas vous configurez le système pour avoir.
Donc, pour la tâche spécifique de l'exécution d'un processus en plusieurs, en parallèle des morceaux, je prends la tâche, de la diviser en "morceaux", et puis de l'envoyer de chaque pièce sur le Message de la File d'attente, où les banques multilatérales de développement les exécuter. Si je puis me permettre 10 instances de la MDB, je peux avoir 10 "parties" d'une tâche en cours d'exécution simultanément.
Cela fonctionne étonnamment bien. Il y a un peu de surcharge, il fractionnement du processus de routage à travers la file d'attente JMS, mais c'est au fond "démarrage". Une fois qu'il se passe, vous obtenez un avantage réel.
Un autre avantage de l'utilisation de la File d'attente de Message c'est que vous pouvez avoir votre long processus en cours d'exécution sur une machine séparée, ou vous pouvez facilement créer un cluster de machines afin de répondre à ces processus. Pourtant, l'interface est la même, et le code ne sait pas la différence.
J'ai trouvé une fois que vous avez relégués à un long processus en cours d'exécution en arrière-plan, vous pouvez payer le prix d'avoir moins-que-accès instantané à ce processus. Qui est, il n'y a aucune raison de surveiller l'exécution des classes elles-mêmes directement, demandez-lui simplement de publier des informations intéressantes et de statistique de la base de données, ou JMX, ou quoi que plutôt que d'avoir quelque chose qui peut surveiller l'objet directement, car il partage le même espace mémoire.
J'ai été capable de créer un cadre qui permet l'exécution de la tâche sur l'EJB de la Minuterie ou sur la base de données de dispersion de la file d'attente, les tâches sont les mêmes, et j'ai pu suivre leurs progrès, les arrêter, etc.
Vous pouvez combiner l'éparpillement technique pour créer plusieurs EJB les travaux du Minuteur. L'un des avantages de la MDB est qu'il agit comme un pool de threads qui peuvent accélérateur de vos travaux (si vous n'avez pas soudainement de saturer votre système avec trop de processus en arrière-plan). Vous obtenez ce "gratuit" juste en tirant parti de l'EJB fonctions de gestion dans le conteneur.
Enfin, Java EE 6 a un nouveau "asynchrone" (ou quelque chose) qualificatif pour la Session Bean méthodes. Je ne connais pas les détails sur la façon dont cela fonctionne, car je n'ai pas encore jouer avec un nouveau conteneur Java EE 6. Mais j'imagine que vous n'allez probablement pas à vouloir changer conteneurs, juste pour cette installation.
OriginalL'auteur Will Hartung
Un EJB est en fin de compte d'un composant transactionnel pour un système client-serveur fournissant de demande/réponse de la sémantique. Si vous vous trouvez dans la position que vous avez besoin de classer une transaction de longue durée dans le cadre d'une demande/réponse de cycle, puis, quelque part votre système d'architecte(ure) a pris le mauvais virage.
La situation que vous décrivez est proprement et correctement manipulés par un événement basé sur une architecture avec une messagerie back-end. Événement Initial initie le processus (qui peut ensuite être trivialement parallélisée en ayant les travailleurs de s'abonner à l'événement le sujet) et l'agrégation des processus de pose en elle-même un événement sur son achèvement. Vous pouvez toujours presser de ces séquences dans les limites d'une demande/réponse de cycle, mais vous aurez par la nécessité de violer la lettre et l'esprit de Java EE architecture du système spécifications.
Il n'y a rien de mal à ce que vous décrivez dans le contexte d'un cadre ou d'une plate-forme qui est spécifié et conçu avec de telles opérations dans l'esprit. Mais ce n'est pas la plate-forme JEE. Le point de l'ensemble de JEE est l'adoption de contraintes à promouvoir la distribution et la disponibilité (et maintenant oublié objectif de l'orientation du composant). Une fois que vous commencer à briser les contraintes vous sont effectivement sur une auto vaincre chemin. Donc, nous devons être en désaccord sur le point de rejet de la mauvaise utilisation de la technologie comme un cas d'un point de vue dogmatique ("noir et blanc").
"demande/réponse de la sémantique... un événement basé sur une architecture avec une messagerie back-end", je vois votre point si la demande sematnics sont "exécution d'un processus à long terme" et la réponse est "à long terme, le processus est terminé". Mais ne serait-il s'intégrer dans le modèle JEE si la demande signifie "démarrer le processus à long terme" et la réponse est "processus à long terme en file d'attente"? Puis, comme une autre réponse suggère, les EJB peut simplement envoyer un message à l'aide de JMS pour obtenir le travail fait par un MDB (ou même un non-JEE à la consommation du message).
Le manque de soutien pour long processus en cours d'exécution est une longue lacune dans l'architecture JEE (qui n'a pas été abordée par les Bmd), mais en toute équité, il n'est pas clair pour moi comment concilier transparence de la distribution, de l'ACO, et exigeant Sla avec de tels éléments. JEE ensemble des adresses via le Connecteur de l'Architecture et vraisemblablement vous fournira le transactionnel moteur d'exécution (EIE), qui gère le long processus en cours d'exécution(es), etc.
OriginalL'auteur alphazero
Retour vers le Futur - Java EE 7 a beaucoup plus de Simultanéité de soutien via ManagedThreadFactory, ManagedExecutor service, etc (JSR 236: la Simultanéité des Utilitaires pour Java EE) avec lequel vous pouvez créer votre propre " géré'Threads .Il n'est plus un sujet tabou dans l'EE de soutien (Wildfly ?) via usining la ManagedThread* API
Plus de détails
https://jcp.org/aboutJava/communityprocess/ec-public/materials/2013-01-1516/JSR236-EC-F2F-Jan2013.pdf
http://docs.oracle.com/javaee/7/tutorial/doc/concurrency-utilities002.htm
JBoss as 7.1 implémente déjà EJB 3.1 spécification. Vous pouvez utiliser la méthode Asynchrone invocation pour de simples cas d'utilisation. N'oubliez pas de configurer le pool de threads sur le serveur d'applications pour répondre à vos besoins.
OriginalL'auteur Alex Punnen
Une fois, j'ai participé à un projet où les EJB transactions a couru jusqu'à 5 heures. Aargh!
Cette même demande avait également un BEA consultant spécialisé qui a approuvé qu'ils ont commencé les threads supplémentaires de ces opérations. Alors qu'il est disrecommended dans les specs et d'ailleurs, il n'est pas automatiquement entraîner une défaillance. Vous devez être conscient que vos fils sont à l'extérieur du conteneur de contrôle et donc si quelque chose va mal c'est de ta faute. Mais si vous pouvez vous assurer que le nombre de threads a commencé dans le pire des cas ne dépasse pas les limites du raisonnable, et qu'ils ont tous mettre fin à proprement dans un délai raisonnable, alors il est tout à fait possible de travailler de cette manière. En fait, dans votre cas, il semble que la quasi-seule solution.
Il y a quelques légèrement ésotérique solutions possible dans le cas où votre application EJB tend la main à une autre application pour un service qui n'a dès lors le multithreading en lui-même avant de retourner à l'EJB de l'appelant. Mais c'est essentiellement juste déplacer le problème autour de.
Vous pouvez, cependant, envisager un regroupement de threads solution pour garder une limite supérieure sur le nombre de threads est généré. Si vous avez trop de threads votre application se comporte très mal.
OriginalL'auteur Carl Smotricz
Vous avez analysé la situation tout à fait bien, et non, il n'est pas patern pour ce match que le modèle EJB.
La création de threads est principalement interdit car il contourner le app. thread du serveur de gestion stratégie et aussi en raison de la transactions.
J'ai travaillé sur un projet similaire requireements et j'ai décidé de spawn des threads supplémentaires (allant à l'encontre de la pec à l'époque). L'opération a été parallélisé en lecture seule, donc ça a au sujet de la transaction (le thread, fondamentalement, n'ont pas de transaction qui leur sont associés). Je savais aussi que je ne fraie pas trop de threads par EJB appels, de sorte que le nombre de threads n'était pas un problème. Mais si vos fils sont censés modifier les données, alors vous briser le modèle transactionnel de l'EJB au sérieux. Mais si votre opération dans le plus pur calcul, qui peut être ok.
Espère que ça aide...
OriginalL'auteur ewernli