The bean is marked as re-entrant. I agree it's hard to find a place in the spec that deals with this specifically. It just seems like it violates the notion of a transaction. Chapter 11 of the spec states "The transactional system ensures that a unit of work either fully completes, or the work is fully rolled back" and in my case I'm making a change that is getting lost.
--- Juan Pablo Lorandi <[EMAIL PROTECTED]> wrote: > Which server? > > Looking at the spec, it seems a grey area (tough I'd > have expected it > worked the way you're using it). Still, on some > servers the sequence you > describe wouldn't work unless the EJB is marked as > re-entrant. > > Check out sections 8.4 and 9.1.4... Graphs here seem > to indicate that no > persistance > call in between ejbCreate(...) and > ejbPostCreate(...) is allowed. > > However, section 9.5.2 does provide grounds to your > line of reasoning > (plus, it makes much more sense). Could you please > name the server > brand? > > Juan Pablo Lorandi > Chief Software Architect > Code Foundry Ltd. > [EMAIL PROTECTED] > > Barberstown, Straffan, Co. Kildare, Ireland. > Tel: +353-1-6012050 Fax: +353-1-6012051 > Mobile: +353-86-2157900 > www.codefoundry.com > > > > -----Original Message----- > > From: A mailing list for Enterprise JavaBeans > development > > [mailto:[EMAIL PROTECTED]] On Behalf Of > fname lname > > Sent: Saturday, April 13, 2002 5:55 PM > > To: [EMAIL PROTECTED] > > Subject: ejbLoad called on modified entity > > > > > > The EJB 1.1 server I'm using is doing something I > > don't like and I'd like to find out how other > vendors > > are handling this situation. Your comments will > be > > greatly appreciated. > > > > Both Entity A and Entity B have transaction > attribute > > set to required. > > [-----EJB Container-----] > > client Entity A Entity B > > | | | > > |***********>| | > > | [create] | > > | [postCreate]*****>| > > | | | > > | |<**callBack*| > > | | | > > > > 1) The client calls create on Entity A > > 2) Entity A ejbCreate executes > > 3) Entity A postCreate modifies its state and > passes > > a reference to itself to Entity B like so: > > this.field1 = "Hello"; > > B b = bHome.findByPrimaryKey("1"); > > b.passA( myRemote ); > > 4) Entity B calls a method on A using the > reference it > > was passed. > > THIS IS THE PART I DON'T LIKE--> just before B > calls > > back on A, ejbLoad is getting called on A, having > the > > affect of losing the modifications within A up > until > > that point. > > > > A trace of the lifecycle methods is shown below: > > AImpl.setEntityContext > > AImpl.ejbCreate > > AImpl.ejbPostCreate > > BImpl.setEntityContext > > BImpl.ejbCreate > > BImpl.ejbPostCreate > > BImpl.passA > > AImpl.ejbLoad CALLED ON MODIFIED ENTITY!! > > AImpl.callBack > > AImpl.ejbStore > > AImpl.setEntityContext > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Tax Center - online filing with TurboTax > http://taxes.yahoo.com/ > > ======================================================================== > === > To unsubscribe, send email to [EMAIL PROTECTED] > and include in the > body of the message "signoff EJB-INTEREST". For > general help, send > email to [EMAIL PROTECTED] and include in the > body of the message > "help". > > =========================================================================== > To unsubscribe, send email to [EMAIL PROTECTED] > and include in the body > of the message "signoff EJB-INTEREST". For general > help, send email to > [EMAIL PROTECTED] and include in the body of the > message "help". > __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
