On 09/09/2008 09:55 PM, Kenneth Saks wrote:
>>
>> If the method is already started and mayInterruptIfRunning is true,
>> the executing thread is interrupted. Right?
>
> We can't have the container just stop the thread of an active business
> method while it's executing. It would leave the
> instance in an unknown state and likely break data integrity. The
> bean developer at least has the option of explicitly
> checking isCancelled() and exiting gracefully.
By nature session beans are not transactional themselves. If they would
be backed by transactional memory, then yes I would be in favor of
having them interrupted. In the proposal it would force the burden of
maintaining data integrity onto the bean developer by use of the thread API.
Hence we went for the wasCancelCalled option. Note that there was a
valid comment by David Lloyd that the usage of j.u.c.Future in that
regard is an abomination, but alas that is all history.
Carlo
On 09/25/2012 11:03 PM, Marina Vatkina wrote:
> Jeremy,
>
> I understand your concern. My counter-argument is that support for
> thread interruption is a basic Java SE feature, and it will be
> counter-intuitive to require bean providers to opt-in into it.
>
> But I'm definitely interested in other opinions (even if they are "do
> not have a preference").
>
> thanks,
> -marina
>
> Jeremy Bauer wrote:
>> Marina,
>>
>> I agree that this is a useful feature. My primary concern is that
>> enabling the new behavior by default may break existing applications.
>> Before giving it a +1, I'd like to hear a contrary argument or that
>> we'll gate the feature, with the new behavior being non-default.
>>
>> -Jeremy
>>
>>
>>
>> From: Marina Vatkina <marina.vatkina_at_oracle.com>
>> To: jsr345-experts_at_ejb-spec.java.net,
>> Date: 09/24/2012 06:53 PM
>> Subject: [ejb-spec users] [jsr345-experts] Re: Interrupting
>> async invocation on Future.cancel request?
>> ------------------------------------------------------------------------
>>
>>
>>
>> Jeremy, Experts,
>>
>> I think it is very useful to require the EJB container to interrupt the
>> running thread on Future.cancel(true) call. It will not only allow the
>> code that has no access to the SessionContext to short-circuit the long
>> running process, but follow more closely the coding patterns in a
>> non-Java EE applications.
>>
>> Please let me know if you think otherwise.
>>
>> For the reference, this is the description of the outcome of the
>> Thread.interrupt call:
>> http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#interrupt()
>> <http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#interrupt%28%29>
>>
>>
>> -marina
>>
>> Marina Vatkina wrote:
>> > Hi Jeremy,
>> >
>> > Jeremy Bauer wrote:
>> >> Hi Marina,
>> >>
>> >> I appreciate the usefulness of this capability, but it has some
>> >> implications for any code that is executing at the time of the
>> >> interrupt.
>> > If the code doesn't have the Thread.isInterrupted() check, nothing
>> > wrong would happen, it will continue executing as before. Are you
>> > concerned about the code that the async method may be invoking
>> > directly or indirectly and which is already written to catch the
>> > InterrupedException, and rethrow it or throw another exception
>> > instead? That code would benefit from a short-circuit behavior because
>> > it will be able to avoid extra processing.
>> >
>> > Another reason for supporting the Thread.isInterrupted() check is that
>> > it is available to any code that can be called by the async method
>> > (vs. SessionContext that needs to be passed around explicitly).
>> >
>> >> The bean may be in the middle of calling a resource, such as a JDBC
>> >> connection, and that resource could be in the middle of i/o, etc.
>> >> External libraries, even components internal to the server itself,
>> >> may not be designed to gracefully handle interrupts. That could
>> >> result in the server and/or resources being left in a bad state.
>> >
>> >
>> > I would expect that JDBC resources to know how to handle an
>> > interruption, and not leave themselves in a bad state (as apposed to
>> > killing the thread, that is indeed a bad idea).
>> >
>> >>
>> >> Also of concern is that the proposal would change current default
>> >> behavior. An existing application, client and/or server side, most
>> >> likely wouldn't be coded to handle the new behavior. If we do go
>> >> with option b) or c), my preference would be to add a switch such as
>> >> @Asynchronous(interruptable=true) that lets a bean provider opt to
>> >> get the new behavior. By opting in, it would be assumed that the a
>> >> bean provider would know and accept the implications - to the bean,
>> >> bean client, and any external library or resource it may be calling -
>> >> of a mid-operation interrupt and would be able to handle the
>> >> interrupt and cleanup appropriately.
>> >
>> > We can do that, but Future.cancel should not be called with
>> > mayInterruptIfRunning=true if the code is not ready to be
>> interrupted...
>> >
>> > But I'd be interested what others think, in particular those who work
>> > on the application part of the world...
>> >
>> > thanks,
>> > -marina
>> >>
>> >> -Jeremy
>> >>
>> >>
>> >>
>> >> From: Marina Vatkina <marina.vatkina_at_oracle.com>
>> >> To: jsr345-experts_at_ejb-spec.java.net,
>> >> Date: 09/12/2012 08:48 PM
>> >> Subject: [jsr345-experts] Interrupting async invocation on
>> >> Future.cancel request?
>> >>
>> ------------------------------------------------------------------------
>> >>
>> >>
>> >>
>> >> 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
>> >>
>> >>
>> >>
>>
>>