Enthuware

I didn't understand the answer for this question.

The explanation is below:

Call from regularM1Int() to asyncM1FutureInt() is a regular method call and it will go to the same object. It is not brokered by the container and the asynchronous semantics will not apply here. Therefore, time taken by the client call to return will be directly affected by the time taken by the asynchronous method to finish. In this case, the client call will not return until at least 10 seconds.

--

Why it's a regular method call?
Why it isn't brokered by the container? Because the caller of the async method is the same object?

If you observe the caller code, it is not using any special EJB handle (such as a reference injected by the container or acquired from the JNDI name space) to call the method. It is using 'this'. Therefore, it is just a regular method call.

Exists the possibility of on InterruptedException be called? (Example: timeout of bean methods execution)

In this case, how I can call the method in asynchronous context but using same bean?

evefuji wrote:Exists the possibility of on InterruptedException be called? (Example: timeout of bean methods execution)

In this case, how I can call the method in asynchronous context but using same bean?

You can't. As per the state transition diagram in Section 3.6.6, If the bean times out, it goes to "Does not exist" state.

HTH,
Paul.

I was wondering, If the asyncrhonous method asyncM1FutureInt is called by a bussiness interface (@Local or @Remote), would the following choices be correct?

* The client call will not return for at least 10 seconds.
* Time of sleep in the asynchronous method will NOT affect the time that the client call will take to return.

It doesn't matter who invokes an async method. What matters is how is it invoked. If you invoke it through an EJB handle (given to you by the container), then the call will return immediately irrespective of how long the method sleeps inside.