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/@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@lycos.com <mailto:reza_rahman@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 >>>> >>>> >>>> >>>> >