On 12/14/12 8:58 AM, Linda DeMichiel wrote:
>
> 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.)
It still holds all of it state after the exception. And e.g. the state
after a failed transaction can be verified and operation retried or the
specific cause of the failed commit can be reported.
>
> 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.
You can't convert a PersistenceException or a
TransactionRolledBackException to an AE using annotations, and marking
them in the ejb-jar.xml will apply to all beans in the same module.
> 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
>>