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.
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.
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);
}
}
Carlo
>
> Thanks for catching it,
> -marina
>>
>> Carlo
>>
>> On 01/11/2012 09:44 PM, Marina Vatkina wrote:
>>> 4.3.3 has this updated text (as suggested by Linda):
>>>
>>> •The getBusinessObject(Class businessInterface)method returns a
>>> business object reference to the session bean’s business interface
>>> or no-interface view. In the case of the no-interface view, the
>>> argument is of the type of the bean class. Only session beans with
>>> an EJB 3.x business interface or no-interface view are permitted to
>>> call this method.
>>> If a subsequent invocation were made on the result of
>>> getBusinessObject, then:
>>> •For a stateless session bean, the invocation would be delivered to
>>> another stateless session bean instance.
>>> •For a stateful session bean or singleton session bean, the
>>> invocation would be delivered to the bean instance that returned the
>>> reference. The existing rules regarding reentrancy would then apply.
>>>
>>>
>>> What did I miss?
>>>
>>> thanks,
>>> -marina
>>>
>>> Carlo de Wolf wrote:
>>>> It looks like SessionContext.getBusinessObject on a SFSB still does
>>>> not support single threaded re-entrant calls. Which it inherently is.
>>>>
>>>> http://java.net/projects/ejb-spec/lists/jsr345-experts/archive/2011-10/message/8
>>>>
>>>> EJB 3.2 EDR 4.3.3
>>>> EJB 3.2 EDR 4.3.13
>>>>
>>>> Carlo
>>>>
>>>> On 12/17/2011 01:22 AM, Marina Vatkina wrote:
>>>>> Experts,
>>>>>
>>>>> I uploaded EDR versions of both books of the EJB 3.2 spec. Please
>>>>> review the changes before the books go to the JCP site for an
>>>>> official submission. If you don't have any comments, please let me
>>>>> know if you are ok with the EDR in its current state.
>>>>>
>>>>> The books have the change bars (the Optional Chapters changes are
>>>>> very minor) and all the changes are listed in the Revision History
>>>>> sections.
>>>>>
>>>>> Other than all the cleanups and clarifications (thank you very
>>>>> much to everybody who helped with this activity), the following
>>>>> had been added to/changed in the spec (the corresponding parts of
>>>>> the revision history are prepended with *New:*) :
>>>>>
>>>>> * Added asynchronous session bean invocations and non-persistent
>>>>> EJB Timer Service support to EJB 3.2 Lite.
>>>>> * Removed restriction to obtain the current class loader; changed
>>>>> ‘must not’ to ‘should exercises caution’ when using the Java I/O
>>>>> package.
>>>>> * Added support for the lifecycle callback interceptor methods of
>>>>> stateful session beans to execute in a transaction context
>>>>> determined by the bean’s transaction management type and any
>>>>> applicable transaction attribute.
>>>>>
>>>>> Have a nice reading!
>>>>>
>>>>> -marina
>>>>>
>>>>>
>>>>>
>>>>
>>