Hi Alex,
asbriglio_at_cesi.fr wrote:
> Hi Marina, experts and users,
> Concerning, the question, thanks to Marina’s clarifications, I would
> opt for adding B) and C) statements. For C) it should be more
> interesting that the container throws an InterrupedException (or an
> EJB API –equivalent exception) rather an EJBException.
>
InterrupedException is a checked exception, so unless the bean method
declares it, we can't do it (sorry for confusion), but it can be
attached as the cause to the EJBException
> I think, Jeremy is right saying that the @Asynchronous should have an
> attribute to turn on the container’s interruption capability
> (interruptible=true). With this attribute a bean provider “agrees” not
> only to turn on the current behavior but also that he has to "play"
> with the Thread API (isInterruped).
>
It does not need to, it can still use SessionContext. *And* I'm still
waiting for others to voice their opinions ;)
> If you decide to add B) and C) statements in the specification, may I
> suggest that you add in the EJB-SPEC 16.2.2 (programming restrictions),
> that an enterprise bean shoud not use Thread.interrupt() :”...The
> enterprise bean must not attempt to start, stop, suspend, resume or
> interrupt a thread…”
>
It's a very good suggestion.
thanks,
-marina
> Regards,
> Alex
>