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.