Configurando os Métodos Assíncronos de EJB Usando Script
Use o script wsadmin para configurar os métodos assíncronos Enterprise JavaBeans (EJB).
Antes de Iniciar
Sobre Esta Tarefa
Procedimento
- Ative a ferramenta de script wsadmin usando a linguagem de script Jython.
- Determine os atributos no objeto de configuração EJBAsync que devem ser atualizados. É possível atualizar os seguintes atributos no objeto de configuração EJBAsync:
Tabela 1. Atributos no Objeto de Configuração EJBAsync. Esta tabela descreve os atributos no objeto de configuração EJBAsync. Atributo Description maxThreads Especifica o número máximo de encadeamentos usados na execução dos métodos de EJB assíncronos. O valor padrão é 5.
workReqQSize Especifica o tamanho da fila de pedidos de trabalho. A fila de pedidos de trabalho é um buffer que mantém métodos assíncronos solicitados até que um encadeamento esteja disponível para executá-los. A soma dos atributos maxThreads e workReqQSize é o número total de solicitações de método em andamento permitidas.
Por exemplo, se maxThreads for configurado para 5 e o workReqQSize for configurado para 50, o número total de solicitações de métodos em andamento permitidas será 55.
O valor padrão é 0, indicando que o tamanho da fila é gerenciado pelo ambiente de tempo de execução. O tempo de execução usa atualmente o maior de 20 e maxThreads.
workReqQFullAction Especifica a ação tomada quando o conjunto de encadeamentos é esgotado e a fila de solicitação de trabalho está cheia. Se configurada para 1, ocorrerá uma exceção ao invés de espera para que um encadeamento, ou um local na fila fique disponível.
Se configurado para 0, o encadeamento que está solicitando a execução do método assíncrono aguardará até que um encadeamento ou local na fila fique disponível.
O valor padrão é 0.
customWorkManagerJNDIName Especifica o nome da Java™ Naming and Directory Interface (JNDI) usada para consultar o gerenciador de trabalho definido pela customização no namespace. O valor padrão é nulo.
useCustomDefinedWM Especifica se uma instância do gerenciador de trabalho definido, customizado é usada ou a instância do gerenciador de trabalho interno padrão. Quando o atributo useCustomDefinedWM estiver configurado para true, significará que uma instância do gerenciador de trabalho customizado será usada. Neste caso, o atributo customWorkManagerJNDIName deverá ser configurado e todos os outros atributos serão ignorados.
Quando o atributo useCustomDefinedWM estiver configurado para false, a instância do gerenciador de trabalho interna será usada. Neste caso, o atributo customWorkManagerJNDIName será ignorado, e todos os outros atributos serão usados para ajudar a configurar a instância do gerenciador de trabalho padrão.
O valor padrão é false
futureTimeout Especifica a quantia de tempo, em segundos, em que o objeto futuro no lado do servidor, criado como resultado da execução de um método assíncrono fire-and-return, estará disponível. O objeto futuro no lado do servidor não será válido após chamar o método get() e um valor retornará para o cliente remoto. Para evitar fugas de memória, você deve chamar o método get() no objeto futuro, ou especificar um valor de duração futuro positivo e diferente de zero. Um valor de duração futuro de zero indica que o objeto futuro nunca expira.
O valor padrão é 86400, o que significa que o objeto futuro expira e é limpo pelo servidor de aplicativos após 24 horas e não estará mais disponível.
Uma exceção org.omg.CORBA.OBJECT_NOT_EXIST ocorre quando uma chamada para o método get() é feita depois que o objeto futuro expira.
Configurações suportadas: Esse valor é aplicável apenas aos clientes que chamam o enterprise bean usando uma interface de negócios remota; o valor não é usado para as visualizações de interface de negócios local ou sem interface. Quando o trabalho assíncrono for concluído, o servidor configurará um alarme para a duração especificada do objeto futuro no lado do servidor. Quando o alarme é ativado, o servidor libera todos os recursos associados ao objeto futuro, tornando-o indisponível para o cliente. Se o cliente chama o método get() no objeto futuro antes do tempo de duração, o alarme será cancelado e todos os recursos associados ao objeto futuro serão liberados.sptcfg
Configurações suportadas: Esse atributo pode afetar o número de objetos futuros no servidor. Use as estatísticas de PMI AsynchFutureObjectCount para determinar a contagem de FutureObjects abertos no servidor, o que pode ajudá-lo a determinar se os aplicativos estão acumulando objetos futuros sem chamar o método get() nesses objetos. Consulte o tópico Contadores de Enterprise Bean para obter mais informações.sptcfg
- Obtenha uma referência para o objeto de configuração EJBAsync correto e armazene-a em uma variável.
Utilizando Jacl:
set async [$AdminConfig list EJBAsync]
Utilizando Jython:
async = AdminConfig.list('EJBAsync')
Se tiver um ambiente com diversos servidores, diversos objetos de configuração EJBAsync serão retornados. Faça um loop na lista programaticamente e selecione o objeto de configuração EJBAsync que corresponde ao servidor que deve ser atualizado.
Em um ambiente com diversos servidores, como uma alternativa para fazer loop programaticamente na lista de objetos EJBAsync, é possível selecionar manualmente o objeto EJBAsync correto e copiar e colá-lo em sua variável.
Por exemplo, a saída do comando AdminConfig list é:
(cells/myNode04Cell/nodes/myCellManager01/servers/dmgr|server.xml#EJBAsync_1)(cells/myNode04Cell/nodes/myNode04/servers/server1|server.xml#EJBAsync_1247498700906)
É possível copiar e colar a referência para o objeto EJBAsync necessário em sua variável.
Utilizando Jacl:
set async "(cells/myNode04Cell/nodes/myNode04/servers/server1|server.xml#EJBAsync_1247498700906)"
Utilizando Jython:
async = "(cells/myNode04Cell/nodes/myNode04/servers/server1|server.xml#EJBAsync_1247498700906)"
- Atualize os atributos no objeto de configuração EJBAsync.
Atualize os atributos no objeto de configuração EJBAsync usando o comando AdminConfig modify. Como entrada para o comando, especifique a referência EJBAsync obtida na etapa anterior e uma lista de combinações de attributeName e attributeValue.
Para configurar uma contagem máxima de encadeamentos para 10 encadeamentos, um tamanho de fila de 15 e um futureTimeout de 3600 segundos:
Utilizando Jacl:
set update "{maxThreads 10} {workReqQSize 15} {futureTimeout 3600}" $AdminConfig modify $async $update
Utilizando Jython:
AdminConfig.modify(async, '[ [maxThreads "10"] [workReqQSize "15"] [futureTimeout "3600"] ]')
- Salve as mudanças na configuração.
Utilizando Jython:
AdminConfig.save()
Utilizando Jacl:
$AdminConfig save
- Apenas em um ambiente de Implementação de Rede, sincronize o nó.
Utilizando Jacl:
set sync1 [$AdminControl completeObjectName type=NodeSync,node=<your node>,*] $AdminControl invoke $sync1 sync
Utilizando Jython:
sync1 = AdminControl.completeObjectName('type=NodeSync,node=<your node>,*') AdminControl.invoke(sync1, 'sync')
Você deve executar a sincronização de nós nesses exemplos enquanto estiver conectado ao servidor.
Resultados


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