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 untilcommit 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
Hi Charlie,If you're looking for the "write side" of the issue, try issuing anEntityManager.flush() to force writing changes to the open connection.Then, any connection with read uncommitted semantics will see the changes. I don't know how to handle the "read side" if you cannot set read uncommitted on the connection properties. Craig On Mar 24, 2008, at 3:03 PM, Charlie Walker wrote:-- Charlie Walker - Registered Linux User #62358"Now and then we had a hope that if we lived and were good, God would permitus 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!
smime.p7s
Description: S/MIME cryptographic signature
