Novo na spec EJB 3.1, essa é a uma das features mais desejadas e pedidas. É muito comum nós precisarmos fazer um request e esquecer o resultado, pois nós sabemos que esse dado processamento vai demorar por conta do requerimento, etc.

Nesses casos, podemos usar o novo @javax.ejb.Asynchronous annotation para retornar o controle para o cliente antes do EJB ser invocado. Se o cliente precisa do valor de retorno, este pode tê-lo pela api java.util.concurrent.Future.

Basicamente para um método ser assíncrono, é simples assim:

//com retorno

@Asynchronous

public Future<String> myMethod() {

// Wrap and return

return new AsyncResult<String>("qualquer coisa");

}

//sem retorno

@Asynchronous

public void myMethod(){}

Considerações importantes a fazer, antes de continuar:

1. Métodos Assíncronos podem ser aplicados a qualquer session bean, sejam Stateful, Stateless ou Singleton beans;
2. Um método assíncrono sempre criará um novo contexto de transação para sua execução, mesmo que esse tenha sido chamado um contexto de transação criado em seu cliente e o transaction attribute seja REQUIRED. Ou seja, o contexto do cliente não é propagado.
3. Um método assíncrono de retorno void não pode lançar uma application exception. Isso só é permitido para métodos assíncronos com retorno Futute<V>.
4. O contexto de segurança é propagado normalmente para métodos assíncronos, como já acontece com métodos não assíncronos.

Possíveis questões para OCE-EJBD6:

Considerando o bean:

@Asynchronous

public void myAsyncMethod() {

System.out.println("In regularM2void");

if(true) throw new RuntimeException("RTE");

}

//client

beanRef.myAsyncMethod();

System.out.println("done");

O que é correto?

1) Obterá um javax.ejb.EJBException e “done” não será impresso.

2) Obterá um javax.ejb.EJBException e “done” será impresso.

3) Obterá um RuntimeException e “done” não será impresso.

4) Não obterá qualquer exception e “done” será impresso.

Resposta:

Nesse caso dois conceitos se misturam, primeiro deles é que o esse cliente unca receberá uma exception vinda desse método, pois tão logo o método é chamado ele retornará para o cliente a execução, e por isso um assíncrono método com retorno void não pode declarar exceções checadas. Por sempre voltar a execução para o cliente “done” sempre será impresso.

Logo, resposta correta é o item 4.

Questão 2:

Quais desses métodos são válidos em um session bean:

1)  @Asynchronous public void getItDone() throws Exception{  //valid code}

2) public void getItDone() throws Exception{  //valid code}

3) @Asynchronous public Future<void> getItDone() {  //valid code}

4) @Asynchronous public void getItDone() {  //valid code}

5) @Asynchronous void getItDone() throws Exception {  //valid code}

Resposta: opções 2 e 4 são válidas.

Opção 1 não é válida, pois decalara um método assíncrono de retorno void com uma exceção checada, o que não é permitido. É permitido declaras essas exceptions com retorno Future<V>.

Opção 3 não é válida pois Future<void> é inválido.

Opção 5 não é válida pois não é permitido um método de session bean não ser público.

Questão 3:

Qual afirmativa é correta?

1) The security principal of the caller propagates to the target bean’s asynchronous method.

2) The security principal of the caller propagates to the target bean’s asynchronous method only if the target bean specifies so in its deployment information.

3) The security principal of the caller propagates to the target bean’s asynchronous method only if the target bean and the caller bean specify so in their deployment information.

4) The security principal of the caller is never propagated to the target bean’s asynchronous method.

5) The target bean is executed as “system” during the asynchronous call.

Resposta: opção 1. Um método assíncrono mantém as regras de segurança dos sessions beans. Logo, o principal do cliente será propagado para o método assíncrono normalmente como acontece com outros métodos do de qualquer session bean.

Por hoje é isso!