RE: Complex Integrity Checking

[Aponte, Tony]

Title: RE: Complex Integrity Checking

I once had an instructor that said "a test is worth a thousand pages of documentation."  If you have access to the book, give the sample a try. 

 

Regards,

 

Tony Aponte

-----Original Message-----
From: Khedr, Waleed [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 10, 2002 11:29 AM
To: Multiple recipients of list ORACLE-L
Subject: RE: Complex Integrity Checking

Again I do not see anything here saying that the child session (Autonomous TX) will see the changes made by the parent TX.

 

If you implied this in your message, then we are in agreement.

 

regards,

 

Waleed

-----Original Message-----
From: Aponte, Tony [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 10, 2002 10:16 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: Complex Integrity Checking

Sorry for the delayed reply (I type with 2 fingers.)  The section starts on page 685.

<<< rip >>>>>
Database Changes
Now, this is were things get interesting - database changes.  Here, things can get a little murky.  Database changes made, but not yet committed by a parent transaction are not visible to the autonomous transactions.  Changes made, and already committed by the parent transaction, are always visible to the child transaction.  Changes made by the autonomous transaction may or may not be visible to the parent depending on its isolation level.

I said before though, that this is were things get murky.  I was pretty clear above in saying that changes made by the parent transaction are not visible to the child but that's not 100 percent of the story.  A cursor opened by the child autonomous transaction will not see uncommitted changes, but a cursor opened by the parent and fetched from the child will.  The following case shows how this works.  We will recreate our EMP  ..................

<<< end rip >>>>>

The rest of the section demonstrates the voodoo magic.  I confess that we didn't go this route and used the global array in a PL/SQL package, and the author discourages the use of autonomous transactions to get around mutating table errors.  But it might be just right for someone's need.

Regards,

Tony Aponte

-----Original Message-----
From: Khedr, Waleed [mailto:   
Sent: Thursday, June 06, 2002 12:08 PM
To: Multiple recipients of list ORACLE-L
Subject: RE: Complex Integrity Checking

I could not find this and do not know how it could happen!

If you can post here what you read, it will be appreciated.

Waleed

-----Original Message-----
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: 6/6/02 9:26 AM

Waleed,
 
The chapter on Autonomous transactions demonstrates how to give the
child transaction the ability to see uncommitted changes made by the
parent transaction.
 
Regards,
 
Tony Aponte

-----Original Message-----
Sent: Wednesday, June 05, 2002 9:03 PM
To: Multiple recipients of list ORACLE-L

The problem with this solution is the Autonomous Transactions  will not
be able to see any changes done within the current transaction only the
committed one. So no way to enforce business logic during the context of
the transaction.
 
This is why I asked before how frequently commit happens.
 
Regards,
 
Waleed

-----Original Message-----
Sent: Wednesday, June 05, 2002 6:33 PM
To: Multiple recipients of list ORACLE-L

With the introduction of Autonomous Transactions this is no longer
entirely true.  If you call an autonomous transaction procedure, it is
executed in a separate transaction context.  This gives you the ability
to probe the mutating table without inducing the error.  A good
explanation can be found in Tom Kyte's Export One-on-one Oracle book in
the chapter on Autonomous Transactions.

HTH
Tony Aponte

-----Original Message-----
<mailto:[EMAIL PROTECTED]> ]
Sent: Wednesday, June 05, 2002 9:24 AM
To: Multiple recipients of list ORACLE-L

no matter what you do, if you access table A inside a trigger on table
A,
oracle will give you mutating table error. What you could (and I really
mean
you have to consider your business logic here) is go ahead and insert
the
rows with a temp flag. As soon as you commit, fire up a procedure that
will
do the scan on the table and delete appropriate rows which have the temp

status.

BTW how big is this table? What is the frequency of inserts and updates?

Raj
______________________________________________________
Rajendra Jamadagni              MIS, ESPN Inc.
Rajendra dot Jamadagni at ESPN dot com
Any opinion expressed here is personal and doesn't reflect that of ESPN
Inc.

QOTD: Any clod can have facts, but having an opinion is an art!

--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Khedr, Waleed
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).