Weighing in on this issue at Marina's request.
I agree with the concerns expressed earlier by Jeremy Bauer
http://java.net/projects/ejb-spec/lists/jsr345-experts/archive/2012-09/message/9
and Carlo de Wolf
http://java.net/jira/browse/EJB_SPEC-73
Hence (a) below.
-Linda
On 9/12/2012 6:47 PM, Marina Vatkina wrote:
> Experts,
>
> I was looking at the rules for canceling long-running async methods in the current spec, and if and how we can improve
> them.
>
> This is what the EJB spec says on the subject (see 3.4.8.1.1Future.cancel):
>
> 1) "If a client calls cancel on its Future object, the container will attempt to cancel the associated asynchronous
> invocation /only/ if that invocation has not already been dispatched".
>
> 2) "If the mayInterruptIfRunning flag is set to true, then subsequent calls to the SessionContext.wasCancelCalled method
> from within the associated dispatched asynchronous invocation must return true. [...] If the dispatched asynchronous
> method does decide to short circuit its processing as a result of checking SessionContext, it the responsibility of the
> Bean Provider to decide how to convey that information to the client"
>
> I.e. after the method had started execution, the container is not expected to do anything, even if the
> mayInterruptIfRunning flag is set to true, and it becomes a bean provider responsibility to implement support for
> cancellation that would look like this:
>
> while (true) {
> doNextPart();
> if (sctx.wasCancelCalled())
> break;
> else
> doSomethingElse();
> }
>
> Which might be good enough, but I am interested in your opinion on adding support for interrupting the thread of
> execution if the method invocation had already started when the Future.cancel is called?
>
> Please let me know if:
> a) You think, it is good enough and we should not make any changes to the Future.cancel handling
>
> b) You think that we should add the following statement to the spec (and modify the current statements accordingly): "If
> a client calls cancel(true) on its Future object while the associated asynchronous invocation is in progress, the
> container will interrupt the thread of execution. It is the responsibility of the Bean Provider to handle
> InterrupedException or check the thread interrupted state and decide how to convey that information to the client".
>
> c) In addition to (b), require the EJB container to throw an exception (InterrupedException or EJBException) if an
> interrupted thread attempts to invoke an EJB method that the container interposes on.
>
> thanks,
> -marina
>
>