The rationale for destroying the bean is that it may be in an
inconsistent state and thus not safely useable (i.e, use might result
in data corruption, etc.)
The point of application exceptions is that they are designed for
cases that the application should be able to handle. This proposal,
if I am understanding it correctly, seems to suggest that system exceptions
be treated as application exceptions. I think that is the wrong thing
to do.
On 12/13/2012 2:21 PM, Marina Vatkina wrote:
> Experts,
>
> I was looking at comments for http://java.net/jira/browse/EJB_SPEC-24 and one of the issues listed is that a SFSB is
> destroyed by the container if a business method throws a system exception (see section "4.6.3Dealing with Exceptions" in
> the latest version of the spec). I have seen many questions from the users that are surprised by one of the
> NoSuchXXXExceptions. It can also be an issue if a SFSB can be used as a websocket endpoint (I'm discussing with the
> websockets spec lead if it's possible).
>
> We can easily solve this problem by adding a global 'retainIfException' flag as an attribute on a @Stateful annotation
> (and a corresponding DD). If added, the default will be false for backward compatibility, and the
> @Remove(retainIfException) will override the bean level setting, if any.
>
> Please vote yes/no on the following 3 items:
>
> 1) we should add the bean-level retainIfException flag to SFSB
>
Definitely not
> 2) if added, the flag should apply to the business methods only (I think so - only PrePassivate might be considered, but
> it would make everything too complicated, and we've already added passivationCapable=false to avoid passivation altogether)
>
No
> 3) if you agree with 2), should the flag be called 'retainIfBusinessMethodException' to avoid confusion?
>
> thanks,
> -marina
>