Modèle de programmation de client pour les méthodes asynchrones EJB
Comme indiqué dans la spécification Enterprise JavaBeans (EJB) 3.1, vous pouvez appeler des méthodes asynchrones EJB à travers les types d'interface suivants : locale métier, distante métier, vue sans interface. Les appels via une vue de client EJB 2.1 ou une vue de service Web ne sont pas autorisés.
La spécification d'interface pour une méthode asynchrone EJB doit avoir le type de retour void ou le type de résultat java.util.concurrent.Future <V>. L'interface ne prend en charge aucun autre type de retour. Comme documenté dans la spécification EJB 3.1, la méthode d'implémentation du bean doit avoir le même type de retour.
Quand votre application n'a pas besoin d'examiner le résultat d'un appel de méthode asynchrone d'EJB, utilisez une signature d'interface avec un type de retour void. Inversement, si votre application a besoin d'examiner le résultat d'un appel de méthode asynchrone d'EJB, utilisez une interface avec un type de retour Future<V>.
Outre l'examen des résultats, les clients doivent être préparés à gérer des exceptions. Comme décrit dans la spécification EJB 3.1, le client reçoit une exception si le conteneur ne peut pas affecter les ressources internes requises pour planifier l'exécution de la méthode asynchrone. Dans ce cas, le client peut considérer que la méthode asynchrone ne s'exécute pas. De même, des exceptions peuvent se produire pendant que la méthode asynchrone s'exécute dans l'unité d'exécution hors client.
Important : Quand une méthode asynchrone a un type de retour void, le client ne dispose d'aucun mécanisme pour récupérer les données des exceptions. Le conteneur EJB consigne un message d'information dans son fichier journal dans ce cas. En revanche, avec les méthodes asynchrones ayant le type de retour Future<V>, le conteneur EJB enregistre les données des exceptions dans l'objet Future<V>. Dans ce cas, les méthodes get associées à l'objet Future<V> permettent d'obtenir l'exception ExecutionException. Le client doit appeler la méthode getCause sur l'exception ExecutionException pour en récupérer les données.
Notez que l'exécution de la méthode get sur l'objet Future<V> bloque l'unité d'exécution du client si la méthode asynchrone n'a pas fini de s'exécuter au moment où get est appelée. Si vous voulez éviter ce comportement, le client doit interroger l'objet Future<V> pour déterminer si la méthode asynchrone a fini de s'exécuter en appelant périodiquement la méthode isDone.
Enfin, les clients peuvent utiliser l'objet Future<V> pour annuler un appel de méthode asynchrone. Si vous tentez d'annuler un appel de méthode asynchrone alors qu'il est encore en attente d'exécution, il n'est pas exécuté et les autres interactions avec l'objet Future<V> reflètent l'annulation. En revanche, si vous tentez d'annuler un appel alors que la méthode asynchrone a déjà commencé à s'exécuter, elle poursuit son exécution, mais la méthode du bean peut encore déterminer que le client a tenté d'annuler l'appel et répondre avec une valeur de retour ou une exception spécifiques à l'application.
Autre alternative, le client peut utiliser la méthode get, qui inclut un paramètre de délai d'expiration. Cette méthode get attend les résultats uniquement pendant le temps spécifié par le délai d'expiration. La méthode get revient vers le client dès la fin de son exécution ou à l'expiration du délai d'attente, même si elle n'a pas fini de s'exécuter.

Lisez la section Développement de code client appelant des méthodes asynchrones d'EJB.