Wasn't the point of this exercise to get from an unspecified transaction
context in lifecycle methods to a specified one?
Although I could be wrong. 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
> >>>>
> >>>>
> >>>>
> >>>>
> >
>