Hi,
In my opinion, when a client does an asynchronous call on an EJB, he
accepts to lose a tight coupling on the process implemented by the
asynchronous method: the caller and the callee cannot be in the same
transactional context, the caller can do an interleaving invocation on
the Session Bean before the asynchronous method returns... Luckily (or
not) he cans politely informs the container that he’d like to cancel
this asynchronous process.
So think you have to keep the fact that’s it’s up to the bean
provider to decide if he wants to be informed of this “cancel” request
and how he wants to handle it.
For those reasons, I you have to modify something about the
asynchronous specification, it should be that the SessionContext.
wasCancelled() can return true even after the call has been dispatched
to the bean instance. Moreover, SessionContext has been designed to
reflect the client call and to be for the bean provider the open door
to the container, so it would be logic if the interruption of the
asynchronous method results of an invocation on SessionContext. If not,
I think it’s better let the bean provider to take another right
decision. In any events it’s not a good idea to “automatically”
interrupt the thread of execution.
I agree that it’s a bad idea to invoke Thread method in a bean’s method
because it’s breaking a part of the container role (too much
intrusive). For me EJB are not the right place to maniple Thread.
Regards,
Alex
PS: For Stateful beans, I don’t see very well the interest of an
asynchronous method outside a coupling with @Remove method.