We upped the ante in EJB 3.1 FR 21.4.5.2:
"The invocation of these methods occurs in the same transaction and
security context as the client’s call to the create method."
We can not back it out again without sacrificing backwards compatibility.
In other words EJB 3.1 FR 21.4.5.2 supersedes EJB 2.1 FR 7.5.9.
In essence we specified the transactional behavior of ejbCreate &
ejbRemove. See also EJB 3.1 FR 4.3.15 where we removed the restrictions
of having database operations in ejbCreate/ejbRemove (@Init/_at_Remove).
So EJB 3.1 FR 4.6.1 remains broken.
Carlo
On 12/06/2011 11:02 PM, Linda DeMichiel wrote:
> OK, I did some archeology (into the EJB 3.0 spec documents) at
> Marina's request.
>
> More below...
>
> On 12/2/2011 1:44 PM, Marina Vatkina wrote:
>> Guys,
>>
>> We have a problem...
>>
>> The spec (see the 3.2 core doc) has in most cases the statement like in
>>
>> ========
>> 4.6.1Operations Allowed in the Methods of a Stateful Session Bean Class
>> (1st bullet under table 1)
>> "The PostConstruct, PreDestroy, PrePassivate, PostActivate, Init,
>> and/or ejbCreate<METHOD>, ejbRemove, ejbPassivate, and
>> ejbActivate methods of a session bean with container-managed
>> transaction demarcation execute with an unspecified
>> transaction context."
>> ========
>>
>
> The spec is quite consistent in the above.
>
>> But there is also this text:
>>
>> ========
>> 16.4.5.2Stateful Session Beans
>> The invocation of the home create<METHOD>() method causes
>> construction of the bean instance, invocation of the
>> PostConstruct lifecycle callbacks, if any, and invocation of the
>> matching Initmethod, and returns the corresponding
>> local component interface or remote component interface of the bean.
>> The invocation of these methods occurs in the same
>> transaction and security context as the client’s call to the create
>> method.
>> ========
>>
>
> This is the problem statement. It was originally in the EJB Simpified
> API spec
> document, and then was merged into the Core Contracts in EJB 3.1.
>
> While one could theoretically argue that it is technically correct
> insofar as the
> create method is executed in an unspecified transaction and security
> context, I think
> that it is misleading. To make things clearer, I would suggest just
> deleting the
> last sentence of the paragraph.
>
>> Should I add everywhere when I change the text about the unspecified
>> transaction context for SFSBs "unless PostConstruct
>> lifecycle callback method is executed as a result of invocation of
>> the home create<METHOD>() method"?
>>
>
> no
>
>> If yes, should I add an opposite note in the 16.4.5.2?
>>
>
> no
>
>> If not, please advise...
>>
>
> I suggest just deleting the sentence that is causing confusion.
>
> If any of you are EJB 3.0 veterans and remember differently, please
> speak up now :-)
>
> thanks,
>
> -Linda
>
>
>> thanks,
>> -marina
>>
>> Jean-Louis MONTEIRO wrote:
>>> Well, that's definitely a popular request.
>>>
>>> If we wanna support transactions, REQUIRES_NEW is the only relevant
>>> attribute to use in my opinion.
>>> I guess from the discussion that we want to support transactions in
>>> SFSB and Singleton, but not yet for SLSB and MDB.
>>> Right?
>>>
>>> Jean-Louis
>>>
>>>
>>>
>>>
>>> 2011/12/1 Reza Rahman <reza_rahman_at_lycos.com
>>> <mailto:reza_rahman_at_lycos.com>>
>>>
>>> I think this is the right change to make. In case of roll-back,
>>> the instance should become unusable. In this case
>>> REQUIRES==REQUIRES_NEW
>>>
>>>
>>> On 11/30/2011 8:54 PM, Marina Vatkina wrote:
>>>
>>> Experts,
>>>
>>> Looking at the long thread on this subject (XXX Transactional
>>> execution of a PostConstuct or PreDestroy method of a
>>> singleton session bean), I'm confused on the outcome of the
>>> discussion...
>>>
>>> Did we reach an agreement to allow transactional support for
>>> Pre/Post lifecycle callback methods of a SFSB (i.e. SLSB and
>>> MDB are not changed in this release)?
>>>
>>> If yes, did we agree that Required would mean RequiresNew in
>>> the transactional attributes (i.e. their execution is never a
>>> part of the client's transaction)?
>>>
>>> What would happen with a SFSB instance if transaction is
>>> rolled back during execution of the lifecycle callback?
>>>
>>> thanks,
>>> -marina
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com <http://www.avg.com>
>>> Version: 2012.0.1873 / Virus Database: 2102/4649 - Release
>>> Date: 11/30/11
>>>
>>>
>>>
>>>