Evan, > I would suggest that your R&D folks disable deferred inserts > by default. This really is an optimization that is not strictly > valid according to the EJB spec. (It is of course valid if the > deployer specifies that deferred inserts are acceptable).
I don't believe the spec invalidates deferred updates. (If it actually does suggest that deferred updates are not strictly valid, then I would be interested in the section where it does mention that). > (1) ejbCreate returns. > > (2) ejbPostCreate calls a session bean which queries the underlying > DBMS table and can't find the row which corresponds to the newly > 'created' entity. > > (3) At some later time, ejbStore is called and does the insert. > Too late now, as the session bean didn't work. I believe the Container should call the ejbStore() on the newly created entity bean instance prior to executing step (2). This is required by the spec (and also what I suggested in my first posting - the write to the database would occur when some other transaction/bean wanted to work with that bean instance - say a finder method etc). So, in step (2), since the Container would be forced to write to the database - the session bean's query results would be consistent. > Hopefully one day we'll have a J2EE CTS test for entity beans that > verifies the default behaviour of entity bean lifecycle isn't > 'cheating'. If the spec actually suggests that deferring database writes is not a valid (default) behavior . . . then you're probably right. -krish =========================================================================== 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".
