Skip navigation
2011

With EJBs we have made the bean developer all powerful. But who is the actual consumer of these beans, not the bean developer. It is the client calling the bean. I think we went the wrong way.

 

So I made a proposal to reverse this trend for @Asynchronous, see Asynchronous *Client* Invocation Semantics. On which Arjan Tijms came up with an interesting addition:

This interface can then be specified at the injection point:

 

@EJB @Asynchronous(ClientInterface.class)
ClientInterface bean; // interface methods are asynchronous and proxy to actual proxy

 

Then I went on and filed for a change to allow setting the transaction timeout of a request.

 

David Blevins not only envisioned it in the same style as we have it currently on JBoss AS, but also brought back the point of having the client as a central focus:

Using your example, imagine how cool this would be:

 

@Stateless [edit: any managed bean] class FooBean {
  @EJB OtherBean other;

  @TransactionAttribute(NEVER)
  public void doSomething() {

     @TransactionTimeout(30)
     @TransactionAttribute(REQUIRED)
     other.doSomethingElse();
  }
}

@Stateless class OtherBean {
  public void doSomethingElse() {
     assert currentTransactionTimeout() == 30;
  }
}

 

Now musing on these on a Friday afternoon. It might actually be possible to realizable both without the need for JSR-308.

 

@Stateless class OtherBean {
   public void doSomethingElse() {
      assert currentTransactionTimeout() == 30;
   }
}

interface ClientInterface {
   @Asynchronous
   @TransactionTimeout(30)
   @TransactionAttribute(REQUIRED)
   Future<Void> doSomethingElse();
}

Future<Void> result = ClientInvocationContext.invoke(bean).with(ClientInterface.class).doSomethingElse();

 

Albeit not as pretty as it would be with type annotations, it should make the customer rule again.