Historically and by default -- YES. Triggers are considered all part of the same exact transaction.
Not only are they part of the transaction but they are atomic with respect to the firing statment. What I mean by that is if you have tables T1, T2 and T3 and table T1 has a trigger to insert into T2 and T2 has one to insert into T3 and you execute:
insert into T1 values ( ... );
either:
o both triggers and all three INSERTS succeed or
o all fail and are undone.
the insert is atomic -- its sideeffects (the triggers) are part of it. Either all of the triggers fire and succeed or they are all undone. To take that further lets say you execute:
insert into some_table values ( ... ); /* this succeeds */
insert into t1 values ( .... ); /* this fails */
After executing these two statements -- the work done by the second insert is "undone" (including any side effects from the triggers) but the work done by the FIRST insert is still there -- you need to either commit it or roll it back.
Now, there are somethings you can do in plsql that are not transactional -- writing to a file for example, or changing the value of a global variable in a package. These operations are NOT undone -- only the inserts/updates/deletes you do are. Therefore, if the trigger writes to an ascii file -- then closes the file and then FAILS -- the file will still exist, we cannot roll that back. In cases like this where I want the file to exists IF and ONLY IF the transaction succeeds, I use DBMS_JOB to schedule the procedure to write the file right AFTER I commit. In that fashion -- that operation that cannot be rolled back will execute after I succeed (and if it fails, the job queues will report the error to me via enterprise manager or a simple query).
In the beginning, I said "historically". Starting with Oracle8i, release 8.1 -- it is possible to have an "autonomous" transaction. they break this rule. See
</code>
http://asktom.oracle.com/~tkyte/autonomous/index.html <code>
for info on that feature.