Experts, please let me know your opinion on the proposed change.
thanks, -marina
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 >>> >>> >>> >>>