Carlo de Wolf wrote:
> Wasn't the point of this exercise to get from an unspecified
> transaction context in lifecycle methods to a specified one?
Yes.
> Although I could be wrong.
We do want to switch from unspecified (for SFSBs) to "be possible to
specify". But on the way there, I stumbled upon an error in the spec
(21.4.5.2) where unspecified was incidentally defined as specified
(thank you Linda for the clarifications). All sections in 3.2 will be
changed to "be possible to specify", irrespective of what they said in 3.1.
Best,
-marina
> In that case I un-ask the question. ;-)
>
> Carlo
>
> On 12/07/2011 07:29 PM, reza_rahman_at_lycos.com wrote:
>> Well said.
>>
>> Dec 7, 2011 01:09:20 PM, jsr345-experts_at_ejb-spec.java.net
>> <mailto:jsr345-experts_at_ejb-spec.java.net> wrote:
>>
>>
>>
>> On 12/7/2011 1:34 AM, Carlo de Wolf wrote:
>> > 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.
>> >
>>
>> As I mentioned, this wasn't introduced in EJB 3.1. This section
>> (under "Adapting
>> EJB 3.x Session Beans to the Earlier Client Views") was taken
>> verbatim from the
>> EJB 3.0 Simplified API document. Ken merged the contents of that
>> document into
>> the Core Contracts because he didn't want to carry along a
>> document that was
>> largely intended as a guide to the simplifications of EJB 3.0.
>>
>> While we wanted to do due diligence with regard to
>> interoperability of earlier
>> client views, it is even today not clear to me how relevant it
>> actually was
>> to support plugging in beans written to the EJB 3.0 APIs under
>> interfaces
>> written
>> to the clunky EJB 2.x Home/Component APIs. In other words, I see
>> this as a
>> real corner case. By the time EJB 3.2 is released, it will be
>> even less
>> relevant.
>> That said, IIRC, when I wrote the offending text, I had no
>> intention of
>> introducing
>> transactionality into methods where it wasn't intended to be
>> supported.
>> Again, if any of you EJB 3.0 veterans recall a different
>> intention here, please
>> speak up!
>>
>> > In other words EJB 3.1 FR 21.4.5.2 supersedes EJB 2.1 FR 7.5.9.
>> >
>>
>> Rather, I would say that EJB 3.0 appears to have contradicted
>> itself, and this
>> was preserved by the cut-and-paste into EJB 3.1.
>>
>> > 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.
>> >
>>
>> It is 21.4.5.2 that is broken, not 4.6.1.
>>
>> Linda
>>
>> > 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, 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 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"?
>> >>>
>> >>
>> >> 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> <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>
>> <http://www.avg.com>
>> >>>> Version: 2012.0.1873 / Virus Database: 2102/4649 - Release
>> >>>> Date: 11/30/11
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >
>>
>