On 12/13/2012 11: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
>
> 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)
>
> 3) if you agree with 2), should the flag be called
> 'retainIfBusinessMethodException' to avoid confusion?
>
> thanks,
> -marina
>
I would rather say that those users do not truly understand the nature
of the SFSB. The whole idea of system exceptions is identifying
programmer errors and thus it signifies the death of the SFSB. This
makes exception handling in EJB a well defined means, instead of the
ill-defined RuntimeException / Exception behavior of SE. Then again I'm
not opposed to exposing 'expert' configuration.
1) only if retainIfSystemException
2) apply to any business method and lifecycle callback interceptor
methods (as per current spec)
3) see 1 and 2 :-)
Note that I do not see the relevance to concurrency. If a system
exception is thrown from a container interceptor (security, transaction,
concurrency etc) it does not necessarily signify the death of the SFSB.
Carlo