Thanks David. I'll reopen the issue, but it will now need to wait until
the next release.
-marina
On 3/11/13 5:21 PM, David Blevins wrote:
> 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
>>>>
>>>>