Hi Alex,
Just to make it clear - thread interruption is not killing or stopping a
thread, but rather either turning on the marker (similar to the
SessionContext behavior) that can be checked anywhere on that thread
(which includes other beans called by the asynchronous method), or
throwing InterruptedException from withing wait() methods at the time of
Thread.interrupt call. See
http://docs.oracle.com/javase/7/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html
for details on the Thread.interrupt vs. Thread.stop behavior.
Now, InterruptedException is a checked exception, so if the async method
was calling e.g. methods of the BlockingQueue that might throw this
exception, they would have a try-catch block around the call, and should
be prepared to handle it (even if it wasn't thrown).
So the changes that I'm proposing are not that drastic, just more
in-line with the expected Java programming style.
HTH.
Best,
-marina
asbriglio_at_cesi.fr wrote:
> 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.
>