Configuration des méthodes asynchrones EJB à l'aide du scriptage
Utilisez le scriptage wsadmin pour configurer les méthodes asynchrones EJB (Enterprise JavaBeans).
Avant de commencer
Pourquoi et quand exécuter cette tâche
Procédure
- Lancez l'outil de scriptage wsadmin via le langage de scriptage Jython.
- Déterminez les attributs dans l'objet de configuration EJBAsync à mettre à jour. Vous pouvez mettre à jour les attributs suivants dans l'objet de configuration EJBAsync :
Tableau 1. Attributs de l'objet de configuration EJBAsync. Ce tableau décrit les attributs de l'objet de configuration EJBAsync. Attribut Description maxThreads Spécifie le nombre maximal d'unités d'exécution utilisées lors de l'exécution des méthodes EJB asynchrones. La valeur par défaut est 5.
workReqQSize Indique la taille de la file d'attente des demandes de travaux. Il s'agit d'une mémoire tampon qui conserve les méthodes asynchrones demandées jusqu'à ce qu'une unité d'exécution soit disponible pour leur exécution. La somme des attributs maxThreads et workReqQSize est le nombre total de demandes de méthode en cours autorisé.
Par exemple, si maxThreads est défini sur 5 unités d'exécution et workReqQSize sur 50 unités d'exécution, le nombre total de demandes de méthode en cours autorisé est 55.
La valeur par défaut est 0 et indique que la taille de la file d'attente est gérée par l'environnement d'exécution. Ce dernier utilise la plus grande 20 et maxThreads.
workReqQFullAction Spécifie l'action effectuée lorsque le pool d'unités d'exécution est épuisé et que la file d'attente des demandes de travaux est pleine. Si la valeur est 1, une exception est émise et le système n'attend pas qu'une unité d'exécution ou une place dans la file d'attente se libère.
Si la valeur est 0, l'unité d'exécution demande que l'exécution de la méthode asynchrone attende qu'une unité d'exécution ou une place dans la file d'attente se libère.
La valeur par défaut est 0.
customWorkManagerJNDIName Indique le nom JNDI (Java™ Naming and Directory Interface) utilisé pour rechercher le gestionnaire de travaux personnalisé dans l'espace de nom. La valeur par défaut est null.
useCustomDefinedWM Indique si une instance de gestionnaire de travaux personnalisé ou l'instance de gestionnaire de travaux interne par défaut est utilisée. Si l'attribut useCustomDefinedWM est associé à la valeur true, cela signifie qu'une instance de gestionnaire de travaux personnalisé est utilisée. Dans ce cas, l'attribut customWorkManagerJNDIName doit être défini et tous les autres attributs sont ignorés.
Si l'attribut useCustomDefinedWM est défini sur false, l'instance du gestionnaire de travaux interne par défaut est utilisé. Dans ce cas, l'attribut customWorkManagerJNDIName est ignoré et tous les autres attributs sont utilisés pour configurer l'instance de gestionnaire de travaux par défaut.
La valeur par défaut est false.
futureTimeout Spécifie la durée, en secondes, pendant laquelle le prochain objet côté serveur, qui est créé suite à l'exécution d'une méthode asynchrone fire-and-return, est disponible. Le prochain objet côté serveur n'est pas valide après l'appel de la méthode get() et une valeur est renvoyée au client distant. Pour éviter des fuites de mémoire, vous devez appeler la méthode get() sur le prochain objet ou spécifier une valeur de durée future positive et différente de zéro. La valeur de durée future zéro indique que le prochain objet n'expire jamais.
La valeur par défaut est 86400, ce qui signifie que le prochain objet expire et est nettoyé par le serveur d'applications après 24 heures. Il n'est donc plus disponible.
Une exception org.omg.CORBA.OBJECT_NOT_EXIST est émise lorsque la méthode get() est appelée après l'expiration du prochain objet.
Configurations prises en charge: Cette valeur est uniquement applicable aux clients qui appellent le bean enterprise via une interface métier distante ; elle n'est pas utilisée pour les vues d'interface métier locale ou les vues sans interface. Une fois le travail asynchrone terminé, le serveur définit une alarme pour la durée spécifiée pour le prochain objet côté serveur. Lorsque l'alarme est activée, le serveur libère toutes les ressources associées au prochain objet, ce qui le rend inaccessible pour le client. Si le client appelle la méthode get() sur le prochain objet avant la durée spécifiée, l'alarme est annulée et toutes les ressources associées au prochain objet sont libérées.sptcfg
Configurations prises en charge: Cet attribut peut affecter le nombre d'objets futurs sur le serveur. Utilisez la statistique AsynchFutureObjectCount PMI pour déterminer le nombre d'objets FutureObjects ouverts sur le serveur ; elle peut vous aider à déterminer si les applications accumulent des objets futurs sans appeler la méthode get() sur ces objets. Pour plus d'informations, consultez la rubrique relative aux compteurs de beans enterprise.sptcfg
- Obtenez une référence à l'objet de configuration EJBAsync approprié et stockez-la dans une variable.
Langage Jacl :
set async [$AdminConfig list EJBAsync]
En langage Jython :
async = AdminConfig.list('EJBAsync')
Si votre environnement comporte plusieurs serveurs, plusieurs objets de configuration EJBAsync sont renvoyés. Parcourez la liste en boucle à l'aide d'un programme et sélectionnez l'objet EJBAsync qui correspond au serveur que vous devez mettre à jour.
Dans un environnement à plusieurs serveurs, au lieu de parcourir la liste des objets EJBAsync en boucle à l'aide d'un programme, vous pouvez manuellement sélectionner l'objet EJBAsync approprié puis le copier et le coller dans votre variable.
Par exemple, la sortie de la commande AdminConfig list est :
(cells/myNode04Cell/nodes/myCellManager01/servers/dmgr|server.xml#EJBAsync_1)(cells/myNode04Cell/nodes/myNode04/servers/server1|server.xml#EJBAsync_1247498700906)
Vous pouvez copier et coller la référence de l'objet EJBAsync requis dans votre variable.
Langage Jacl :
set async "(cells/myNode04Cell/nodes/myNode04/servers/server1|server.xml#EJBAsync_1247498700906)"
En langage Jython :
async = "(cells/myNode04Cell/nodes/myNode04/servers/server1|server.xml#EJBAsync_1247498700906)"
- Mettez à jour les attributs dans l'objet de configuration EJBAsync.
Mettez à jour les attributs dans l'objet de configuration EJBAsync à l'aide de la commande AdminConfig modify. En entrée, spécifiez la référence EJBAsync que vous avez obtenue à l'étape précédente ainsi que la liste des combinaisons d'attributeName et d'attributeValue.
Pour définir un nombre d'unités d'exécution maximal égal à 10, une taille de file d'attente égale à 15 et associer l'attribut futureTimeout à 3600 secondes, procédez comme suit :
A l'aide de Jacl :
set update "{maxThreads 10} {workReqQSize 15} {futureTimeout 3600}" $AdminConfig modify $async $update
Avec Jython :
AdminConfig.modify(async, '[ [maxThreads "10"] [workReqQSize "15"] [futureTimeout "3600"] ]')
- Sauvegardez les modifications de configuration.
Avec Jython :
AdminConfig.save()
Avec Jacl :
$AdminConfig save
- Dans un environnement Network Deployment uniquement, synchronisez le noeud.
Avec Jacl :
set sync1 [$AdminControl completeObjectName type=NodeSync,node=<your node>,*] $AdminControl invoke $sync1 sync
Avec Jython :
sync1 = AdminControl.completeObjectName('type=NodeSync,node=<your node>,*') AdminControl.invoke(sync1, 'sync')
Vous devez exécuter la synchronisation du noeud de ces exemples lorsque vous êtes connecté au serveur.
Résultats


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=txml_ejbAsynch_config
Nom du fichier : txml_ejbAsynch_config.html