Re: Question about commit

"Mark C. Stock" <mcstockX_at_Xenquery .com> wrote in news:4PmdnevrfIVHc9fcRVn-gw_at_comcast.com:

>
> "Ana C. Dent" <anacedent_at_hotmail.com> wrote in message
> news:Xns956745E1C17DDSunnySD_at_68.6.19.6...

>| Markus Breuer <markus.breuer_at_gmx.de> wrote in
>| news:cie4qd$s30$1_at_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.
>|

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. Received on Sat Sep 18 2004 - 02:43:50 CEST