Gestionnaires de travaux
Un gestionnaire de travaux fournit des unités d'exécution pour les applications Java™ Platform, Enterprise Edition (Java EE).
- Programmes d'exécution gérés
- javax.enterprise.concurrent.ManagedExecutorService
- javax.enterprise.concurrent.ManagedScheduledExecutorService
- java.util.concurrent.ExecutorService
- java.util.concurrent.ScheduledExecutorService
- Fabriques d'unités d'exécution
- javax.enterprise.concurrent.ManagedThreadFactory
- java.util.concurrent.ThreadFactory
- Service de contexte d'unité d'exécution
- javax.enterprise.concurrent.ContextService
- Beans asynchrones
- com.ibm.websphere.asynchbeans.WorkManager
- Gestionnaire de travaux CommonJ
- commonj.work.WorkManager
Les gestionnaires de travaux fournissent un modèle de programmation pour les applications Java EE. Pour plus d'informations, voir la section Modèle de programmation.

Lors de la conception d'un composant Web ou EJB (Enterprise JavaBeans) qui utilise Concurrency Utilities for Java EE ou des beans asynchrones, le développeur doit inclure une référence de ressource dans chaque composant devant accéder à un programme d'exécution géré, une fabrique d'unités d'exécution, un service contextuel ou un gestionnaire de travaux. Pour plus d'informations sur les références de ressources, voir la rubrique Références. Le composant interroge un programme d'exécution géré, une fabrique d'unités d'exécution, un service contextuel ou un gestionnaire de travaux qui utilise un nom logique résidant dans le composant, espace de noms java:comp, comme il le fait pour interroger une source de données, un bean enterprise ou une fabrique de connexions.
Le déployeur lie les gestionnaires de travaux physiques à des références d'environnement de ressource logiques (programmes d'exécution gérés, fabriques d'unités d'exécution, services contextuels ou gestionnaires de travaux) au moment du déploiement de l'application.
Par exemple, si un développeur requiert trois pools d'unités d'exécution afin de partitionner le travail entre les niveaux bronze, argent et or, il fera en sorte que le composant sélectionne un pool logique en fonction du profil de l'application client. Le déployeur décide de la façon dont la requête sera adressée à l'un des trois pools d'exécution. Il peut également opter pour un seul pool d'exécution si l'application s'exécute sur un système de petite taille. Dans ce cas, il liera les trois références de ressources à la même instance du gestionnaire de travaux (c'est-à-dire au même nom JNDI). Sur une système de plus grande taille, il sera possible d'utiliser trois pools d'unités d'exécution, de sorte que le déployeur liera chaque référence de ressources à un gestionnaire de travaux distinct. Les gestionnaires de travaux peuvent être partagés entre plusieurs applications Java EE résidant sur le même serveur.
Les développeurs d'applications peuvent utiliser autant de références d'environnement de ressource logiques que nécessaire. Le déployeur choisit s'il convient de mapper un ou plusieurs gestionnaires de travaux physiques à un programme d'exécution géré, une fabrique d'unités d'exécution, un service contextuel ou un gestionnaire de travaux logique défini dans l'application.
Tous les composants Java EE contraints de partager des objets de portée asynchrones doivent utiliser le même gestionnaire de travaux. Ces objets de portée possèdent une affinité avec un seul gestionnaire de travaux. Une application qui utilise des portées asynchrones doit vérifier que tous les composants utilisant des objets de portée utilisent également le même gestionnaire de travaux.
Quand plusieurs gestionnaires de travaux sont définis, le programme crée les pools d'unités d'exécution sous-jacents dans une machine virtuelle Java uniquement si une application de cette machine interroge le gestionnaire de travaux. Par exemple, dix pools d'unités d'exécution (gestionnaires de travaux) peuvent être définis, mais aucun n'est créé tant qu'ils n'ont pas été interrogés par une application.
Gestionnaire de travaux CommonJ
Le gestionnaire de travaux CommonJ contient un sous-ensemble des méthodes du gestionnaire de travaux des beans asynchrones. Bien que le gestionnaire de travaux CommonJ fonctionne dans un environnement Java EE, l'interface ne renvoie pas de nouvelle instance pour chaque recherche de nom JNDI, car cette spécification n'est pas incluse dans la spécification Java EE.
La fonction facultative de spécification des travaux CommonJ pour les travaux exécutés à distance n'est pas prise en charge. Même si elle implémente l'interface java.io.Serializable, l'unité de travail n'est pas exécutée à distance.
Mécanisme de recherche d'un programme d'exécution géré
InitialContext ic = new InitialContext();
ManagedExecutorService executor = (ManagedExecutorService) ic.lookup("java:comp/env/concurrent/myExecutor");
Contextes d'héritage Java EE
- Un contexte d'internationalisation
- Lorsque cette option est sélectionnée, que le service d'internationalisation est activé et que le contexte d'internationalisation présent dans l'unité d'exécution de planification est disponible dans l'unité d'exécution cible.
- Espace de travail
- Lorsque cette option est sélectionnée, le contexte de zone de travail correspondant à chaque partition de zone de travail figurant dans l'unité d'exécution de planification est disponible sur l'unité d'exécution cible.
- Profil d'application (déconseillé)
- Le contexte du profil d'application n'est pas pris en charge et n'est pas disponible pour la plupart des applications. Dans les applications Java EE 1.3, lorsque cette option est sélectionnée, le service de profil d'application est activé et la propriété correspondante, Mode de compatibilité 5.x, est sélectionnée. La tâche de profil d'application associée à l'unité d'exécution de planification est disponible sur l'unité d'exécution cible pour les applications Java EE 1.3. Pour les applications Java EE 1.4 ou de niveau ultérieur, la tâche de profil d'application n'est pas une unité d'exécution mais une propriété de l'unité de travail associée. Cette option n'influence pas le comportement de la tâche dans les applications Java EE 1.4 ou de niveau ultérieur. Le travail planifié exécuté dans une application Java EE 1.4 ne reçoit pas la tâche de profilage de l'unité d'exécution de planification.
- Sécurité
- La tâche peut s'exécuter de façon anonyme ou sous le nom du client authentifié auprès de l'unité d'exécution qui l'a créée et soumise. Ce comportement est pratique car la tâche peut obéir totalement aux ordres de l'appelant. En cela, cette fonctionnalité est plus performante que le mécanisme RUN_AS, par exemple, qui ne permet pas un tel comportement. Lorsque vous sélectionnez l'option Sécurité, l'objet JAAS qui figure dans l'unité d'exécution de planification est disponible dans l'unité d'exécution cible. Si cette option n'est pas sélectionnée, l'unité d'exécution fonctionne de manière anonyme.
- Métadonnées du composant
- Les métadonnées du composant n'ont lieu d'être que lorsque la tâche est un objet Java simple. Si la tâche est un composant Java EE, tel qu'un bean enterprise, les métadonnées du composant sont actives.
Les contextes qui peuvent être hérités dépendent du gestionnaire de travaux, qui est utilisé par l'application qui crée et soumet la tâche. A partir de la console d'administration, l'administrateur définit la règle d'héritage de contexte d'un gestionnaire de travaux, en sélectionnant les services pour lesquels le gestionnaire sera disponible.
Modèle de programmation
- Concurrency Utilities for Java EE. La spécification Java EE normalise ce modèle de programmation, qui inclut des programmes d'exécution gérés, des programmes d'exécution planifiés gérés et des fabriques d'unités d'exécution gérées qui héritent de l'API Java SE java.util.concurrent bien connue. Elle inclut également le service contextuel, sans équivalent dans l'API java.util.concurrent.
- Beans asynchrones. Les interfaces actuelles Work Manager, EventSource de beans asynchrones, de portées asynchrones, de moniteurs de sous-systèmes et de contexte Java EE appartiennent au modèle de programmation beans asynchrones.
- Spécification CommonJ. Le modèle de programmation CommonJ utilise les objets WorkManager et TimerManager pour gérer les unités d'exécution et les compteurs en mode asynchrone dans l'environnement Java EE.
Pour plus d'informations sur les API des programmes d'exécution gérés, des fabriques d'unités d'exécution, du service contextuel et du gestionnaire de travaux, voir la documentation Javadoc.
Exemples d'accès concurrents
Programme d'exécution géré | Beans asynchrones | CommonJ |
---|---|---|
|
|
|
Programme d'exécution géré | Beans asynchrones | CommonJ |
---|---|---|
|
|
|
Programme d'exécution géré | Beans asynchrones | CommonJ |
---|---|---|
|
|
|
Programme d'exécution planifié géré | Beans asynchrones | CommonJ |
---|---|---|
|
|
|
Programme d'exécution planifié géré | Beans asynchrones | CommonJ |
---|---|---|
|
|
|