Hi Craig, I don't believe they "override" the setting, a better term would probably be "simulate". They apparently maintain enough information to commit the data but also have the ability to rollback. Here is an excerpt from their documentation. ---------------------------------------------------------------------------------------------------- from "http://e-docs.bea.com/wls/docs100/ejb/entity.html#wp1195783 " Updating the Database Before Transaction Ends
As described in Understanding ejbLoad() and ejbStore() Behavior, by default, WebLogic Server calls ejbStore() only when the transaction commits. To make intermediate results of uncommitted transactions available to other database users, set delay-updates-until-end-of-tx in the persistence element of weblogic-ejb-jar.xml to False�this causes WebLogic Server to call ejbStore() after each method call. Note: While setting delay-updates-until-end-of-tx to false results in database updates after each method call, the updates are not committed until the end of the transaction. ---------------------------------------------------------------------------------------------------- Thanks, Charlie On Tue, Mar 25, 2008 at 1:37 PM, Craig L Russell <[EMAIL PROTECTED]> wrote: > Hi Charlie, > > I'm still confused. What behavior do you see with the delay-updates > set to false? If the database doesn't support read-uncommitted, an > application (weblogic) cannot override this. > > Craig > > On Mar 25, 2008, at 10:25 AM, Charlie Walker wrote: > > > No, the database doesn't support the read-uncommited isolation level > > but > > bea, the ejb2.1 provider, had a weblogic specific setting > > > > "<delay-updates-until-end-of-tx>false</delay-updates-until-end-of-tx>" > > > > which simulated a read-uncommited isolation level. I'm not sure why > > the > > designers of the system chose this route but it is making it > > difficult to > > upgrade. > > > > I appreciate your insight. thanks, > > Charlie > > > > On Tue, Mar 25, 2008 at 12:50 PM, Craig L Russell <[EMAIL PROTECTED] > > > > > wrote: > > > >> Hi Charlie, > >> > >> On Mar 25, 2008, at 6:44 AM, Charlie Walker wrote: > >> > >>> Hi Craig, > >>> Thanks for the help. Let me see if I understand correctly. > >>> > >>> 1. our oracle 10g database only supports "read committed", > >>> "serializable" > >>> and "read only" tranasction isolation levels. > >>> 2. on the "write side", issuing an entitymanager.flush(), forces > >>> the > >>> changes to the database. > >>> > >>> my question: "I thought since the underlying database is set to > >>> "read-committed", after executing the flush, only connections within > >>> the > >>> current transaction would be able to read the changes to the > >>> database until > >>> commit time." Is this correct? > >> > >> That's my understanding as well. And that's what I thought you were > >> asking for. It exactly matches the behavior you described for "set > >> delay-updates-until-end-of-tx to false". > >> > >> If you want dirty reads, the database has to support the read- > >> uncommitted isolation level. Are you migrating from a database that > >> supports read-uncommitted? > >> > >> Regards, > >> > >> Craig > >> > > > > > > -- > > Charlie Walker - Registered Linux User #62358 > > > > "Now and then we had a hope that if we lived and were good, God > > would permit > > us to be pirates." - Mark Twain > > Craig Russell > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo > 408 276-5638 mailto:[EMAIL PROTECTED] > P.S. A good JDO? O, Gasp! > > -- Charlie Walker - Registered Linux User #62358 "Now and then we had a hope that if we lived and were good, God would permit us to be pirates." - Mark Twain
