Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

CHAPTER 8 ■ TRANSACTIONS 259
So, one row was successfully inserted into T and we duly received the message, I fired
and updated 1 rows. The next INSERT statement violates the integrity constraint we have on T.
The DBMS_OUTPUT message appeared—the trigger on T in fact did fire and we have evidence of
that. It performed its updates of T2 successfully. We would maybe expect T2 to have a value of
2 now, but we see it has a value of 1. Oracle made the original INSERT atomic—the original
INSERT INTO T is the statement, and any side effects of that original INSERT INTO T are considered
part of that statement.
Oracle achieves this statement-level atomicity by silently wrapping a SAVEPOINT around
each of our calls to the database. The preceding two INSERTs were really treated like this:
Savepoint statement1;
Insert into t values ( 1 );
If error then rollback to statement1;
Savepoint statement2;
Insert into t values ( -1 );
If error then rollback to statement2;
For programmers used to Sybase or SQL Server, this may be confusing at first. In those
databases exactly the opposite is true. The triggers in those systems execute independently of
the firing statement. If they encounter an error, the triggers must explicitly roll back their own
work and then raise another error to roll back the triggering statement. Otherwise, the work
done by a trigger could persist even if the triggering statement, or some other part of the statement,
ultimately fails.
In Oracle, this statement-level atomicity extends as deep as it needs to. If in the preceding
example, the INSERT INTO T fires a trigger that updates another table, and that table has a trigger
that deletes from another table (and so on, and so on), either all of the work succeeds or
none of it does. You do not need to code anything special to ensure this—it is just the way it
works.
Procedure-Level Atomicity
It is interesting to note that Oracle considers PL/SQL anonymous blocks to be statements as
well. Consider the following stored procedure:
ops$tkyte@ORA10G> create or replace procedure p
2 as
3 begin
4 insert into t values ( 1 );
5 insert into t values (-1 );
6 end;
7 /
Procedure created.
ops$tkyte@ORA10G> select * from t;
no rows selected
ops$tkyte@ORA10G> select * from t2;