Triggers in Oracle

Question

Hi,
I have a question about the behavior of triggers. Consider the following situation:
1. There is a table called TABLE_A.
2. There is a table called TABLE_B.
3. There is a trigger T1 that watches TABLE_A for inserts, and if there is an insert the trigger inserts a row into TABLE_B.
4. There is a trigger T2 that watches TABLE_A for inserts, and if there is an insert the trigger inserts a row into TABLE_B.
5. There is a trigger T3 that watches TABLE_B for inserts, and peforms some action.
6. There is a trigger T4 that watches TABLE_B for inserts, and peforms some action.
My questions are:
1. What is order in which these triggers will execute when a row is inserted into TABLE_A?
2. Will any of the triggers run concurrently (perhaps in different threads?) ?
3. Is the order which triggers run predictable?
4. Is there any way to define priority, synchronous, concurrent behavior with the triggers?
5. Is there any way to define dependency among triggers (e.g. T1 cannot run until T2 finishes running) ?
Thanks in advance,
Galen

Answer 1

Sounds like you're looking for the control offered by different types of triggers, row level vs. statement level triggers. Here is what Oracle Concepts has to say about Trigger execution:
A single SQL statement can potentially fire up to four types of triggers:
BEFORE row triggers
BEFORE statement triggers
AFTER row triggers
AFTER statement triggers
A triggering statement or a statement within a trigger can cause one or more integrity constraints to be checked. Also, triggers can contain statements that cause other triggers to fire (cascading triggers).
Oracle uses the following execution model to maintain the proper firing sequence of multiple triggers and constraint checking:
Run all BEFORE statement triggers that apply to the statement.
Loop for each row affected by the SQL statement.
Run all BEFORE row triggers that apply to the statement.
Lock and change row, and perform integrity constraint checking. (The lock is not released until the transaction is committed.)
Run all AFTER row triggers that apply to the statement.
Complete deferred integrity constraint checking.
Run all AFTER statement triggers that apply to the statement.
The definition of the execution model is recursive. For example, a given SQL statement can cause a BEFORE row trigger to be fired and an integrity constraint to be checked. That BEFORE row trigger, in turn, might perform an update that causes an integrity constraint to be checked and an AFTER statement trigger to be fired. The AFTER statement trigger causes an integrity constraint to be checked. In this case, the execution model runs the steps recursively, as follows:
Original SQL statement issued.
BEFORE row triggers fired.
AFTER statement triggers fired by UPDATE in BEFORE row trigger.
i. Statements of AFTER statement triggers run.
ii. Integrity constraint checked on tables changed by AFTER statement triggers.
Statements of BEFORE row triggers run.
Integrity constraint checked on tables changed by BEFORE row triggers.
SQL statement run.
Integrity constraint from SQL statement checked.
There are two exceptions to this recursion:
When a triggering statement modifies one table in a referential constraint (either the primary key or foreign key table), and a triggered statement modifies the other, only the triggering statement will check the integrity constraint. This allows row triggers to enhance referential integrity.
Statement triggers fired due to DELETE CASCADE and DELETE SET NULL are fired before and after the user DELETE statement, not before and after the individual enforcement statements. This prevents those statement triggers from encountering mutating errors.