Revising my stance on this as I was mistakenly thinking Thread.destroy, which would be cataclysmic. Interrupt is not nearly as terrible.
I'd be fine allowing it with the @Asynchronous(interruptable=true) that both Jeremy and Carlo mention. It addresses the backwards compatibility and also nicely make the developer knowingly opt-in to such functionality and take responsibility for any ill intended side-effects.
-David
On Jan 30, 2013, at 11:33 AM, David Blevins <david.blevins_at_gmail.com> wrote:
> 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
>>>
>>>
>>