Hi Evan, Deferred updates are specifically allowed by the EJB spec in section 10.5.3:
"The container may create the representation of the entity in the database immediately, or it can defer it to a later time (for example to the time after the matching ejbPostCreate<METHOD>(...) has been called, or to the end of the transaction), depending on the caching strategy that it uses." I think the situation you cite, where a session bean directly accesses the state data in the persistent store and sees inconsistent results, is applicable to any situation where data is cached in the transaction. For instance, you might call a setter method on an entity, which does not instantly update the relevant column in the database. A session bean that accesses the persistent store will have an inconsistent view of that column within the transaction. But of course, the alternative is to do no caching within a transaction whatsoever. In the case of CMP 2 entities with their fine-grained accessors, this would of necessity create a blizzard of db i/o and is not realistic. The session bean developer must be aware of this situation (which exists for any type of entity using common data cache strategies for the bean's state, i.e. using ejbLoad() and ejbStore()), and take appropriate application- level action. I believe that finder methods for CMP beans are a different matter entirely. The CMP engine is responsible for ensuring that there is a consistent view of the data for finder methods. If it can't do this with delayed updates, then it can't use delayed updates. Just my two cents for this discussion. -Daniel O'Connor On 29 Jan 2002, at 6:21, Evan Ireland wrote: > Krishnan Subramanian wrote: > > > 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). > > > The spec does not strictly "invalidate" deferred updates. > However the situation where a deferred update causes failure of > a session bean (running in the same transaction (before) the > deferred updates) it could be argued that the container has > failed to "synchronize the state when it needs to". The > relevant piece of the spec reads: > > While the instance is in the ready state, the container can > synchronize the state of the instance with the state of the > entity in the underlying data source whenever it deter-mines > the need to, in the process invoking the ejbLoad() and ejbStore() > methods zero or more times. > > So the argument goes thus: > > > (1) A session bean is accessing the entity's underlying database > representation in the same transaction (as a potentially > deferred update). > > (2) Thereby the container needs to synchronize the state of the > entity before the session bean is called. > > (3) Deferring any updates might result in the session bean seeing > a transaction-inconsistent view of the data. > > (In this argument, you can replace session bean calls with finder > method calls, in the case where the container doesn't consult the > in-memory cache to get additional finder results during the transaction). > > Now, as a developer, if you know this situation cannot arise, you > > may be able to enable deferred updates during deployment. But I > believe it is hard to escape from the conclusion that deferred updates > are not a valid default behaviour (unless your app. doesn't have any > session beans or finder methods). > > > >>(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". > > > > > > > > > > > -- > _______________________________________________________________________________ > > Evan Ireland Sybase EAServer Engineering [EMAIL PROTECTED] > Wellington, New Zealand +64 4 934-5856 > > =========================================================================== > 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".
