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."
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."
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."
To me it looks like we're mixing single-thread, multi-threaded and
re-entrant wrongly.
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
>>>
>>>
>>>
>>