And while you are thinking about your reply, please also look at the
following options:
1. Applying the new option at the bean class (i.e. as a @Stateful attribute)
2. Applying the new option at the method-level only (i.e. as a separate
annotation)
3. Both.
thanks,
-marina
On 12/17/12 11:12 AM, Marina Vatkina wrote:
> 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
>>>>
>>
>