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.
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).
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…”
Regards,
Alex