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