The behavior you'd get by setting that flag to false in weblogic would also allow him to not break referential integrity in the case of his transaction. Scott M Stark wrote: > Why is this a serious problem? The weblogic docs for the flag you mention > indicate the commit is still not done until the end of the transaction and > that you would only notice this if your db allows for uncommitted reads. > > From, http://e-docs.bea.com/wls/docs61///ejb/EJB_environment.html#1048164 > Using delay-updates-until-end-of-tx to Change ejbStore() Behavior > > By default, WebLogic Server updates the persistent store of all beans in a >transaction only at the completion (commit) of the > transaction. This generally improves performance by avoiding unnecessary updates and >repeated calls to ejbStore(). > > If your datastore uses an isolation level of READ_UNCOMMITTED, you may want to allow >other database users to view the intermediate > results of in-progress transactions. In this case, the default WebLogic Server >behavior of updating the datastore only at > transaction completion may be unacceptable. > > You can disable the default behavior by using the delay-updates-until-end-of-tx >deployment element. When you set this element to > "false," WebLogic Server calls ejbStore() after each method call, rather than at the >conclusion of the transaction. > > Note: Setting delay-updates-until-end-of-tx to false does not cause database updates >to be "committed" to the database after each > method invoke; they are only sent to the database. Updates are committed or rolled >back in the database only at the conclusion of > the transaction. > > > > ----- Original Message ----- > From: "David Esposito" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, June 15, 2001 9:01 AM > Subject: [JBoss-dev] ejbStore() delay seems to be a serious problem > > > >>Hello all, >> >>I have spent the past few hours reading up on other people with similar >>problems to mine. So I am familiar with what the EJB spec says (somewhat >>related to the "diamond" scenario (11.7.1 of the EJB Spec)) with respect to >>when a Bean is required to write its data out to persistent storage. >>However, this seems to be counterintuitive and is a serious problem for >>operations that manipulate multiple data sources. >> >> > > > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development >
Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.