Concurrency Utilities for Java EE
Concurrency Utilities for Java™ EE est un modèle de programmation asynchrone qui permet de soumettre ou planifier l'exécution de tâches en parallèle, créer des unités d'exécution qui héritent du contexte Java EE et transférer un contexte Java EE pour démarrer des interfaces, telles que des rappels asynchrones.
Concurrency Utilities for Java EE permet d'améliorer les performances en activant un programme Java EE pour la décomposition des opérations en tâches parallèles.
- Un contexte de sécurité
- Un contexte d'internationalisation
- Un contexte de zone de travail
Interfaces d'accès concurrent
Concurrency Utilities for Java EE fournit quatre types principaux de ressources, chacun d'eux pouvant être configuré et mis à disposition dans JNDI :
- Service de programme d'exécution géré
- Les applications utilisent un programme d'exécution géré pour soumettre des tâches asynchrones qui peuvent démarrer leur exécution en tant qu'unités d'exécution, généralement depuis un pool, quand des ressources sont disponibles pour les exécuter. Les tâches sont des instances de type appelable (Callable) ou exécutable (Runnable). Un future est donnée à l'application, à partir duquel elle peut vérifier l'état et obtenir ou attendre le résultat de fin d'exécution de la tâche. Le programme d'exécution géré inclut des interfaces pour la soumission et l'attente d'achèvement d'un groupe de tâches ou d'une tâche au sein d'un groupe. Les tâches héritent du contexte de l'unité d'exécution qui soumet la tâche.
- Service de programme d'exécution planifié géré
- Les applications utilisent un programme d'exécution planifié géré pour planifier des tâches asynchrones pour un début d'exécution après un point de cohérence donné. Les tâches sont des instances de type appelable (Callable) ou exécutable (Runnable). Le programme d'exécution planifié géré inclut des interfaces pour la replanification automatique d'une tâche, que ce soit à intervalle fixe ou calculé selon une logique applicative personnalisée. Les tâches héritent du contexte de l'unité d'exécution qui planifie la tâche.
- Fabrique d'unités d'exécution gérée
- Les applications utilisent une fabrique d'unités d'exécution gérée pour construire de nouvelles unités d'exécution qui héritent du contexte du composant d'application qui a consulté ou injecté la fabrique d'unités d'exécution gérée.
- Service contextuel
- Les applications utilisent un service contextuel pour construire des proxys contextuels, ce qui permet aux appels d'une ou de plusieurs interfaces de proxy d'hériter du contexte de l'unité d'exécution ayant créé le proxy.
Transactions
Chaque tâche soumise ou planifiée, chaque unité d'exécution de fabrique d'unités d'exécution gérée et chaque opération de proxy contextuel est appelée avec toute transaction qui se trouvait précédemment sur l'unité d'exécution interrompue, de façon similaire aux transactions gérées par conteneur dans des beans enterprise classiques. Ce cas est comparable à la situation dans laquelle une méthode EJB (Enterprise JavaBeans Beans) est appelée avec TX_NOT_SUPPORTED. L'environnement d'exécution lance un confinement de transaction locale avant d'appeler la méthode. La tâche peut démarrer sa propre transaction globale si cette dernière est possible pour le composant Java EE appelant. Vous pouvez remplacer ce comportement pour des proxys contextuels en spécifiant la propriété d'exécution TRANSACTION avec une valeur de USE_TRANSACTION_OF_EXECUTION_THREAD. La propriété permet à la transaction de rester sur l'unité d'exécution afin que les opérations transactionnelles effectuées au sein de la méthode de proxy puissent s'appliquer ou être annulées avec la transaction de l'unité d'exécution appelante.
Lorsque vous appelez un bean entity à partir d'une tâche, par exemple, un contexte transactionnel global doit être disponible dans l'unité d'exécution en cours. Parce que les tâches lancent des contextes transactionnels locaux, vous devez encapsuler la logique de bean entity dans un bean session comportant une méthode marquée comme TX_REQUIRES ou équivalent. Ce processus établit un contexte transactionnel global à partir duquel vous pouvez accéder à une ou plusieurs méthodes de bean entity.
Accès aux métadonnées des composants Java EE
Si une tâche est un composant Java EE, tel qu'un bean session, ses métadonnées sont actives lors de l'appel d'une méthode. Si la tâche est un objet Java simple, les métadonnées du composant Java EE du composant créateur sont disponibles pour le bean. Comme son unité d'exécution de soumission, la tâche peut consulter l'espace de nom java:comp, java:module ou java:app. Cette consultation permet au bean d'accéder à des ressources telles que des sources de données, de fabriques de connexions et des beans enterprise, comme s'il s'agissait d'un autre composant Java EE. Les propriétés d'environnement du composant créateur sont également disponibles pour la tâche.
L'espace de nom java:comp est identique à celui disponible pour le composant créateur et les mêmes restrictions s'appliquent. Si, par exemple, un servlet ou un bean enterprise possède une référence EJB de java:comp/env/ejb/MyEJB, celle-ci est disponible pour la tâche.
Gestion des connexions
Une tâche peut utiliser les sources de données et les fabriques de connexions que le composant Java EE par lequel elles ont été créées a obtenues à l'aide de références de ressource java:comp. (Pour plus d'informations sur les références de ressources, reportez-vous à la rubrique Références). Cependant, la méthode de bean doit accéder à ces connexions à l'aide d'un modèle get-use-close (extraction-utilisation-fermeture). Il n'existe pas de mise en cache des connexions entre les appels de méthode sur une tâche asynchrone. Les fabriques de connexions ou les sources de données peuvent être mises en cache, mais les connexions doivent être récupérées à chaque appel de méthode, puis utilisées et fermées. Bien que la méthode de tâche puisse rechercher des fabriques de connexions et des sources de données en utilisant un nom JNDI (Java Naming and Directory Interface) global, cette solution n'est pas recommandée pour les raisons suivantes :
- Le nom JNDI est codé en dur dans l'application (par exemple, sous forme de propriété ou de littéral chaîne).
- Les fabriques de connexions ne sont pas partagées car il n'existe aucun moyen de spécifier une portée de partage.
La rubrique Exemple : gestion de connexions à accès concurrents décrit les mécanismes à utiliser et les mécanismes à proscrire pour établir des connexions d'accès à partir de tâches.
Lancement différé de tâches contextuelles
Concurrency Utilities for Java EE prend en charge le lancement différé en autorisant la sérialisation des informations de contexte d'unité d'exécution Java EE. Les proxys contextuels peuvent être sérialisés si l'instance fournie à la méthode ContextService.createContextualProxy est sérialisable. A ce stade, le service contextuel crée un instantané des contextes Java EE activés sur le gestionnaire de travaux (WorkManager). Le proxy contextuel qui en résulte peut alors être sérialisé et stocké dans une base de données ou un fichier. Cette procédure est utile lorsqu'il est nécessaire de stocker des contextes de service Java EE, tels que l'identité de sécurité en cours ou la variable locale, puis de les décompresser et d'exécuter des tâches au sein de ce contexte. Toutes les méthodes d'interface du proxy contextuel s'exécutent avec le contexte d'unité d'exécution précédemment capturé.
Tous les proxys contextuels doivent être désérialisés par l'application qui les a sérialisés. Tous les EJB et les classes doivent être présents pour décompresser les objets qu'ils contiennent.
Lancement différé et sécurité
Le contexte du service de sécurité peut requérir l'activation de la fonction Vérification d'identité CSIV2 (Common Secure Interoperability Version 2). La déclaration d'identité est requise quand un proxy contextuel est désérialisé et exécuté par rapport à l'affectation du justificatif d'identité de l'objet JAAS. Pour déterminer si vous devez activer la déclaration d'identité lors de l'utilisation d'un proxy contextuel, consultez les rubriques ci-après :
- Configuration du protocole d'authentification CSIV2 (Common Secure Interoperability version 2) et SAS (Security Authentication Service)
- Vérification d'identité
Des limitations peuvent également exister si vous utilisez des proxys contextuels provenant de différentes versions du produit.
Limitations associées à JPA
L'utilisation de tâches asynchrones dans un contexte de persistance étendu JPA n'est pas prise en charge.
Les contextes de persistance JPA étendus ne sont pas cohérents par rapport aux fonctions de planification et de traitement multitâche de Concurrency Utilities for Java EE. Ils sont en outre inaccessibles à partir des tâches asynchrones.
De même, une tâche asynchrone ne doit pas prendre javax.persistence.EntityManager (ou une sous-classe) comme paramètre car les instances EntityManager ne sont pas destinées à autoriser les unités d'exécution multiples.