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.
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
>>>>