Experts,
Let's return to this discussion...
I got this request from the Java API for Web Sockets spec lead, Danny
Coward:
================================
Request to relax restriction on destroying instances of Stateful Session
Beans:
However, the current EJB specification places the limitation that the
container must remove any instance of a stateful session bean instance
if an invocation to one of its methods generates a runtime exception.
This is a problem for webscket developers because it is integral to the
websocket model that runtime errors arising from, for example, failures
to parse particular incoming websocket messages, can explicitly be
handled by the websocket instance, and the websocket instance continue
to operate. example, in the Java WebSocket API, we have an annotation
called @WebSocketError that allows the developer to mark a particular
method able to process any such errors thrown as the methods on a
websocket endpoint instance are called, and the websocket to continue
operation on the same connection once the error has been properly handled."
We would like the EJB specification not to require instances of
websockets written as stateful session beans to be removed should any of
the websocket instances methods generate runtime exceptions. Ideally,
this would be achieved by explicitly defining this 'relaxed' behavior in
the special case of websockets as stateful session beans, but perhaps we
could live with the EJB spec giving us a new annotation that would 'turn
off' removal of the instance in these cases, and that we would require
websocket developers use when using stateful session beans."
================================
When I asked Danny about method-level vs. bean-level annotations, his
response was:
" the websocket model is to handle errors thrown on any annotated
method, so I think, for us, the bean level is both adequate and less
error prone (should developers forget to add it to one method)."
I see the following options for the SFSBs to be used as websocket
endpoints and not break the websocket API rules:
a) augment the EJB spec to say that an SFSB cannot be destroyed if it is
a websocket endpoint until then end of the websocket conversation
b) add a @Stateful attribute
c) add a method-level annotation @RetainIfSystemException
d) add an annotation @RetainIfSystemException that can be applied at
either the bean level or method level.
Let me know your preference (and please do so asap as we are in the
final stretch.
thanks,
-marina
On 12/21/12 12:42 AM, Carlo de Wolf wrote:
> If you are looking for a means to specify an application exception on
> a method level, then I can agree with a proposal.
> In other words it should be possible for a bean developer to designate
> for example PersistenceException as an application exception for
> certain methods. (A throws clause alone would not be sufficient as it
> can not designate the rollback attribute.)
>
> For retaining the SFSB on system exceptions I side with Linda's
> comments, but allowing explicit retention on system exceptions could
> be considered as an expert user option. Then again we would be
> undermining the very clear exception handling model we have on EJBs.
>
> Carlo
>
> On 12/21/2012 12:56 AM, Marina Vatkina wrote:
>> 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
>>>>>>
>>>>
>>>
>>
>