Oops... Seems I'm gettin' rusty... sorry -----Original Message----- From: Alex Paransky [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 4:58 PM To: Juan Pablo Lorandi Subject: RE: ejbLoad called on modified entity
Juan, I am not actually having a problem, I replied to someone who did. You might wish to repost your message to the forum so that individual receives your valuable input. -AP_ http://www.alexparansky.com Java/J2EE Architect/Consultant http://www.myprofiles.com/member/view.do?profileId=127 -----Original Message----- From: Juan Pablo Lorandi [mailto:[EMAIL PROTECTED]] Sent: Monday, April 15, 2002 11:55 PM To: [EMAIL PROTECTED] Subject: RE: ejbLoad called on modified entity All inline 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 Alex Paransky > Sent: Tuesday, April 16, 2002 6:40 AM > To: [EMAIL PROTECTED] > Subject: Re: ejbLoad called on modified entity > > > There could be a number of problems that can cause this type of > behavior: > > 1. Have you tried wrapping a transaction around the entire operation. > Have your client call on a stateless session bean with "Required" > transaction attribute. Then perform this operation inside of the > session bean's method. If it's an EB, won't all TX settings will be Required, as per the spec? > > 2. If you created your own Primary key class, make sure you properly > implement the hashCode and equals methods. I recently had to trace a > bug very similar to yours, and this was the problem. This sounds like it. > > 3. Have you by any chance created your own isModified() function? > Many servers provide a feature to control your own change state with > regards to the bean. If you accidentally overwrite isModified() to > return a wrong value, you might experience such problems. Also, if you're using Weblogic, I think the function name is isDirty(). Still, provided that no PK confusion is there, it seems like somewhat the server gets a new connection to the DB (with a different rollback stack, of course) to populate the "second" instance of the EB. Of course, I presume ejbCreate and ejbPostCreate are executed within a transactional context. Another idea... Which DB are you using? Which DRIVERS are you using? Is it possible that connection pooling is done by the drivers/DB so that they're messing it up, not the App Server? Please, provide some more info on the scenario. > > You might get better support here if you mention what server you are > working with. Personally, I have worked with the Orion server, and > have earlier experienced such problems. However, with later releases > of Orion they went away. > > -AP_ > http://www.alexparansky.com > Java/J2EE Architect/Consultant > http://www.myprofiles.com/member/view.do?profileId=127 > > -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED]]On Behalf Of fname lname > Sent: Saturday, April 13, 2002 9:55 AM > 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". =========================================================================== 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".
