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
