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.
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. 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. 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".
