Carlo de Wolf wrote:
> On 01/13/2012 01:17 AM, Marina Vatkina wrote:
>> Carlo de Wolf wrote:
>>> On 01/12/2012 03:25 AM, Marina Vatkina wrote:
>>>> Carlo de Wolf wrote:
>>>>> The existing rule:
>>>>> EJB 3.2 EDR 4.3.13:
>>>>> "Therefore, a stateful or stateless session bean does not have to
>>>>> be coded as reentrant."
>>>>
>>>> This is still correct. See below.
>>>>
>>>>>
>>>>> vs
>>>>>
>>>>> 2011-10/message/8
>>>>> "For the stateful session beans and singleton session beans the
>>>>> returned reference will be for the same instance, and the bean
>>>>> must support reentrant calls to call a method on it."
>>>>
>>>> May be I should remove that last part (", and ...") - see also
>>>> below...
>>>>>
>>>>> EJB 3.2 EDR 4.10.13 does have an exception clause. Although it
>>>>> might be more correctly to state:
>>>>> "The container must ensure that only one thread can be executing a
>>>>> stateless or stateful session bean
>>>>> instance at any time.
>>>>> One implication of this rule is that an application cannot make
>>>>> loopback calls to a stateless or stateful
>>>>> session bean instance, unless the invocation were made on the
>>>>> result of SessionContext.get-
>>>>> BusinessObject (in conformance with the requirements of section
>>>>> 4.3.3).
>>>>> Barring an invocation though SessionContext.getBusinessObject,
>>>>> stateful and stateless session beans do not have to be coded as
>>>>> reentrant."
>>>>
>>>> This is definitely needed to be fixed :(
>>>>
>>>> My change (starting with "unless...") does seem to mix reentrance
>>>> and SessionContext.getBusinessObject, which is wrong (sorry). The
>>>> SessionContext.getBusinessObject result is intended to be used only
>>>> for the subsequent invocations (see 4.3.3), not reentrant calls
>>>> (which are not allowed on either SLSB or SFSBs).
>>>>
>>>> I need to revert my change. I can also add a note stating that "The
>>>> object reference returned from SessionContext.getBusinessObject is
>>>> to be used for the subsequent invocations (see 4.3.3), not
>>>> reentrant calls."
>>>>
>>>>>
>>>>> To me it looks like we're mixing single-thread, multi-threaded and
>>>>> re-entrant wrongly.
>>>>
>>>> Multi-threaded access of SFSB is allowed with locks and timeouts.
>>>> Reentrance is not.
>>>
>>> I think we have a different understanding of reentrancy.
>>
>> It's somewhat defined in a singletons chapter:
>>
>> "reentrant calls, i.e., where an outbound call from a singleton
>> session bean method results in a loopback call to the singleton
>> session bean on the same thread."
>>>
>>> To me:
>>> class SFSB {
>>> public String spaces(int i) {
>>> return i > 1 ? " " + ctx.getBusinessObject(SFSB.class).spaces(i - 1)
>>> : " ";
>>> }
>>> }
>>> is reentrant. Although it might be argued that we never the actually
>>> leave the instance boundary.
>>
>> Yes, it is reentrant. And this is prohibited by the spec for MDBs
>> and any session beans other than singletons.
>
> I agree, although the definition of "outbound call" might be
> misinterpreted.
>
> So in effect this means that 2011-10/message/8 has not been processed
> into the spec.
That specific text didn't make it to the spec because I was wrong
suggesting that a session bean (other than a singleton) can be
reentrant. As it is not, Linda's text from 2011-10/message/9 was used
instead.
-marina
>
> Carlo
>
>>>
>>> I'm very interested to hear what would be the expected result of:
>>> class SFSB {
>>> @EJB Caller caller;
>>> public String spaces(int i) {
>>> return i > 1 ? " " +
>>> caller.callMe(ctx.getBusinessObject(SFSB.class)) : " ";
>>> }
>>> }
>>> class Caller {
>>> public String callMe(SFSB me) {
>>> return me.spaces(i - 1);
>>> }
>>> }
>>
>> This is a loopback call, i.e. a reentrant.
>>
>> -marina
>>>
>>> Carlo
>>>>
>>>> Thanks for catching it,
>>>> -marina
>>>>>
>>>>> Carlo
>>>>>
>