Experts,
I'd like to hear opinions from more of you.
thanks,
-marina
On 12/14/12 11:18 AM, Marina Vatkina wrote:
> 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
>>>
>