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.

Reply via email to