"Mark C. Stock" <mcstockX@Xenquery .com> wrote in
news:4P********************@comcast.com:
"Ana C. Dent" <an*******@hotmail.com> wrote in message
news:Xn*********************@68.6.19.6...
| Markus Breuer <ma***********@gmx.de> wrote in
| news:ci**********@pentheus.materna.de:
|
| > I have a question about oracle commit and transactions. Following
| > scenario:
| >
| > Process A performs a single sql-INSERT into a table and commits the
| > transaction. Then he informs process B (ipc) to read the new date.
|
| As strange as this may sound PRIOR to issuing the SELECT,
| Process B needs to issue a COMMIT.
|
That does sound strange... the only reason for this would be if B is
in a read-only transaction... (see my other post).
Issuing a COMMIT to see other user's changes is never a requirement.
Never, say "never". ;-)
If B is in a read-only transaction, then a COMMIT or ROLLBACK should
only be entered when the read-only transaction is completed (per the
business functionality specification), not as a work around to a
scenario that is not yet fully analyzed.
++ mcs
Oracle is too brain dead to know about "read-only" transactions.
Oracle GUARENTEES a read consistant view of the database.
If Process B has issued a SELECT prior to Process A doing the COMMIT,
then Oracle ENSURES Process B won't see the changed data. This is
because Oracle can't know what Process B intends to do with the
data from the 1st SELECT. The only way I know how to convince Oracle
that my process wants to see "new data" is to issue a COMMIT (or
ROLLBACK) to indicate all my previous activity is a completed
transaction.After my session issues a COMMIT, Oracle will present
to my session data as it exists at the time of my next SELECT!
You are free to disagree & provide proof to the contrary.