We discussed this quite a lot in EJB 3.1, but unfortunately that was
mostly on concalls. I do think we got it right though and my vote
would be to stick with the current rules, option A.
-David
On Fri, Dec 21, 2012 at 1:37 PM, Linda DeMichiel
<linda.demichiel_at_oracle.com> wrote:
> 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
>>
>>
>