| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Complex Integrity Checking
I would not be happy to have such instructor!
-----Original Message-----
Sent: Monday, June 10, 2002 12:08 PM
To: Multiple recipients of list ORACLE-L
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-----
Sent: Monday, June 10, 2002 11:29 AM
To: Multiple recipients of list ORACLE-L
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-----
Sent: Monday, June 10, 2002 10:16 AM
To: ORACLE-L_at_fatcity.com
Cc: Waleed.Khedr_at_FMR.COM
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-----
Sent: Thursday, June 06, 2002 12:08 PM
To: Multiple recipients of list ORACLE-L
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: ORACLE-L_at_fatcity.com
Cc: Waleed.Khedr_at_FMR.COM
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:Rajendra.Jamadagni_at_espn.com <mailto:Rajendra.Jamadagni_at_espn.com> >
]
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
QOTD: Any clod can have facts, but having an opinion is an art!
-- Please see the official ORACLE-L FAQ: http://www.orafaq.com <http://www.orafaq.com> -- Author: Khedr, Waleed INET: Waleed.Khedr_at_FMR.COM Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing ListsReceived on Mon Jun 10 2002 - 12:18:24 CDT
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Khedr, Waleed INET: Waleed.Khedr_at_FMR.COM 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: ListGuru_at_fatcity.com (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).
 |
 |