Full Frontal PR: Getting People Talking about You, Your Business, or Your Product
ISBN: 1590595254
EAN: 2147483647
EAN: 2147483647
Year: 2005
Pages: 41
Pages: 41
Authors: Richard Laermer, Michael Prichinello
Autonomous transactions allow you to create a new transaction within a transaction that may commit or roll back changes, independently of its parent transaction. They allow you to suspend the currently executing transaction, start a new one, do some work and commit or roll back, all without affecting the currently executing transaction state. Autonomous transactions provide a new method of controlling transactions in PL/SQL, and may be used in:
Top-level anonymous blocks
Local, standalone, or packaged functions and procedures
Methods or object types
Database triggers
In order to execute the examples in this chapter, you will need Oracle 8.1.5 or higher. Any edition, Standard, Enterprise, or Personal may be used, as this feature is available with all of them.
After looking at a first example of a simple autonomous transaction, we will:
Look at how to use them, including how to implement auditing that cannot be rolled back, prevent mutating tables, write to the database from a SELECT statement, and as a means to develop more modular code.
See how they work. We'll investigate transactional control and scope, how to end an autonomous transaction and how to issue savepoints.
Round off the chapter with caveats and errors that you should look out for when using this feature in your applications.
In order to show what this feature can do, we'll start with a quick example that demonstrates the effects of autonomous transactions. What we'll do is create a simple table to hold a message, along with two procedures: one 'regular' procedure, and the other coded as an autonomous transaction. The procedures will modify the table we created. We'll use these objects to show what work persists (is committed) in the database under various circumstances:
tkyte@TKYTE816> create table t ( msg varchar2(25) ); Table created. tkyte@TKYTE816> create or replace procedure Autonomous_Insert 2 as 3 pragma autonomous_transaction; 4 begin 5 insert into t values ( 'Autonomous Insert' ); 6 commit; 7 end; 8 / Procedure created. tkyte@TKYTE816> create or replace procedure NonAutonomous_Insert 2 as 3 begin 4 insert into t values ( 'NonAutonomous Insert' ); 5 commit; 6 end; 7 / Procedure created.
The procedures simply insert their name into the message table and commit - very simple. Note the use of the PRAGMA AUTONOMOUS_TRANSACTION. This directive tells the database that this procedure, when executed, is to be executed as a new autonomous transaction, independently of its parent transaction. Now, let's observe the behavior of the non-autonomous transaction in an anonymous block of PL/SQL code:
tkyte@TKYTE816> begin 2 insert into t values ( 'Anonymous Block' ); 3 NonAutonomous_Insert; 4 rollback; 5 end; 6 / PL/SQL procedure successfully completed. tkyte@TKYTE816> select * from t; MSG ------------------------- Anonymous Block NonAutonomous Insert
As you can see, the work performed by the anonymous block, its insert, was committed by the procedure NonAutonomous_Insert. Both rows of data were committed, and the rollback had nothing to roll back. Compare this to the behavior of the autonomous transaction procedure:
tkyte@TKYTE816> delete from t; 2 rows deleted. tkyte@TKYTE816> commit; Commit complete. tkyte@TKYTE816> begin 2 insert into t values ( 'Anonymous Block' ); 3 Autonomous_Insert; 4 rollback; 5 end; 6 / PL/SQL procedure successfully completed. tkyte@TKYTE816> select * from t; MSG ------------------------- Autonomous Insert
Here, only the work done by, and committed, in the autonomous transaction persists. The INSERT done in the anonymous block is rolled back by the ROLLBACK statement on line 4. The autonomous transaction procedure's COMMIT has no effect on the parent transaction started in the anonymous block. This simple example captures the essence of autonomous transactions and what they do.
In the absence of autonomous transactions, the COMMIT in the procedure NonAutonomous_Insert committed not only the work it performed (the INSERT of NonAutonomous Insert), but also any outstanding work the session had performed and not yet committed (such as the insert of Anonymous Block in the anonymous block). The rollback rolled back no work, since the procedure call already committed both INSERTs. We see that this is not the case with autonomous transactions. The work performed in the procedure marked with AUTONOMOUS_TRANSACTION was committed; however, the work performed outside the autonomous transaction was rolled back.
Oracle has supported autonomous transactions internally for quite a while. We see them all of the time in the form of recursive SQL. For example, when selecting from a non-cached sequence, a recursive transaction is performed for you to increment the sequence immediately in the SYS.SEQ$ table. The update of the sequence was immediately committed and visible to other transactions, but your transaction was not committed yet. Additionally, if you roll back your transaction, the increment to the sequence remained in place - it was not rolled back with your transaction, as it had already been committed. Space management, auditing, and other internal operations are performed in a similar, recursive fashion. This feature has now been exposed for all to use.
Now that we have seen what an autonomous transaction is, we'll take a look at reasons for using them.
In this section we will explore various scenarios where you might choose to use this feature.
A question that, in the past, was frequently posed by application developers was, 'How can I audit an attempt to modify secure information?' What they want to do is not only prevent the attempted modification from taking place, but also create a permanent record of the attempt. The approach in the past that many have tried to use (and failed) was triggers. The trigger would detect the update and, upon discovering a user modifying data they should not, the trigger would create an audit record and fail the update. Unfortunately, when you failed the update, you also rolled back the audit record - it was an all or nothing failure. Now, with autonomous transactions we can securely capture the audit of an attempted operation, as well as roll back that operation, giving us the ability to tell the end user, 'You cannot modify that data, and we have a record of you attempting to modify it'. It is interesting to note that the native Oracle AUDIT capability gave us the ability to capture unsuccessful attempts to modify information using autonomous transactions for many years. The exposure of this feature to the Oracle developer, allows us to create our own, more customized auditing.
Here is a small example. What we will do is copy the EMP table from the SCOTT schema. We will also create an audit trail table that will be used to capture who tried to update this EMP table and when they tried to do it, along with a descriptive message of what they tried to modify. A trigger, coded as an autonomous transaction, will be placed in the EMP table to capture this information for us:
tkyte@TKYTE816> create table emp 2 as 3 select * from scott.emp; Table created. tkyte@TKYTE816> grant all on emp to scott; Grant succeeded. tkyte@TKYTE816> create table audit_tab 2 ( username varchar2(30) default user, 3 timestamp date default sysdate, 4 msg varchar2(4000) 5 ) 6 / Table created.
The next thing is to create a trigger to audit update activity on the EMP table. Note the use of the autonomous transaction. The logic employed by this trigger is to prevent anyone from updating the record of an employee that does not work for him or her. The CONNECT BY query is adept at resolving the entire hierarchy for us, given the current user. It will verify that the record you are attempting to update is of someone that reports to you at some level:
tkyte@TKYTE816> create or replace trigger EMP_AUDIT 2 before update on emp 3 for each row 4 declare 5 pragma autonomous_transaction; 6 l_cnt number; 7 begin 8 9 select count(*) into l_cnt 10 from dual 11 where EXISTS ( select null 12 from emp 13 where empno = :new.empno 14 start with mgr = ( select empno 15 from emp 16 where ename = USER ) 17 connect by prior empno = mgr ); 18 19 if ( l_cnt = 0 ) 20 then 21 insert into audit_tab ( msg ) 22 values ( 'Attempt to update ' || :new.empno ); 23 commit; 24 25 raise_application_error( -20001, 'Access Denied' ); 26 end if; 27 end; 28 / Trigger created.
So, we have set up the EMP table that has a nice hierarchical structure (EMPNO/MGR recursive relationship). We have an AUDIT_TAB into which we want to record failed attempts to modify information. We have a trigger to enforce our rule that only your manager, or your manager's manager (and so on) may modify your record.
The things to notice in the above trigger are:
PRAGMA AUTONOMOUS_TRANSACTION is applied to the trigger definition. This entire trigger is an autonomous transaction of the parent transaction. A quick word on the term 'pragma'. A pragma is simply a compiler directive, a method to instruct the compiler to perform some compilation option. There are other pragmas available, see the PL/SQL User's Guide and Reference in Oracle's documentation and look in the index for a list of them under pragma.
This trigger on EMP reads from EMP in the query. More on why this is 'earth shattering' in a moment.
This trigger commits. This has never been possible before - triggers could never commit work. This trigger is not committing the work that actually fired the trigger. Rather, it is only committing the work that the trigger has performed (the audit record).
So, let's see how this works then:
tkyte@TKYTE816> update emp set sal = sal*10; update emp set sal = sal*10 * ERROR at line 1: ORA-20001: Access Denied ORA-06512: at "TKYTE.EMP_AUDIT", line 22 ORA-04088: error during execution of trigger 'TKYTE.EMP_AUDIT' tkyte@TKYTE816> column msg format a30 word_wrapped tkyte@TKYTE816> select * from audit_tab; USERNAME TIMESTAMP MSG ------------------------------ --------- ------------------------------ TKYTE 15-APR-01 Attempt to update 7369
So, the trigger caught me and was able to prevent the update from occurring while at the same time creating a permanent record of the attempt (notice how it used the DEFAULT keyword on the CREATE TABLE above to automatically have the USER and SYSDATE values inserted for us). Now, let's log in as a user who can actually do an update and try some things out:
tkyte@TKYTE816> connect scott/tiger scott@TKYTE816> update tkyte.emp set sal = sal*1.05 where ename = 'ADAMS'; 1 row updated. scott@TKYTE816> update tkyte.emp set sal = sal*1.05 where ename = 'SCOTT'; update tkyte.emp set sal = sal*1.05 where ename = 'SCOTT' * ERROR at line 1: ORA-20001: Access Denied ORA-06512: at "TKYTE.EMP_AUDIT", line 22 ORA-04088: error during execution of trigger 'TKYTE.EMP_AUDIT'
In the default EMP table, the employee ADAMS works for SCOTT so the first update succeeds. The second update, where SCOTT tries to give himself a raise, fails since SCOTT does not report to SCOTT. Logging back into the schema where the AUDIT_TAB is located, we see:
scott@TKYTE816> connect tkyte/tkyte tkyte@TKYTE816> select * from audit_tab; USERNAME TIMESTAMP MSG ------------------------------ --------- ------------------------ TKYTE 15-APR-01 Attempt to update 7369 SCOTT 15-APR-01 Attempt to update 7788
The attempt by SCOTT to perform this update is there. The last thing we want to look at is why it is relevant that we read from EMP in the trigger on EMP - 'why is this earth shattering?' This leads us directly into the next section.
A mutating table error can happen for a number of reasons. The most predominant cause is trying to read the table upon which a trigger is firing. In the example above, we clearly read from the table that fired the trigger. If we comment out two lines of this trigger, and we could attempt to use it as follows:
tkyte@TKYTE816> create or replace trigger EMP_AUDIT 2 before update on emp 3 for each row 4 declare 5 -- pragma autonomous_transaction; 6 l_cnt number; 7 begin 8 9 select count(*) into l_cnt 10 from dual 11 where EXISTS ( select null 12 from emp 13 where empno = :new.empno 14 start with mgr = ( select empno 15 from emp 16 where ename = USER ) 17 connect by prior empno = mgr ); 18 19 if ( l_cnt = 0 ) 20 then 21 insert into audit_tab ( msg ) 22 values ( 'Attempt to update ' || :new.empno ); 23 -- commit; 24 25 raise_application_error( -20001, 'Access Denied' ); 26 end if; 27 end; 28 / tkyte@TKYTE816> update emp set sal = sal*10; update emp set sal = sal*10 * ERROR at line 1: ORA-04091: table TKYTE.EMP is mutating, trigger/function may not see it ORA-06512: at "TKYTE.EMP_AUDIT", line 6 ORA-04088: error during execution of trigger 'TKYTE.EMP_AUDIT'
The fact is that without autonomous transactions, the above trigger would be difficult to write, even if all it wanted to do was to verify that you were updating a row you should be allowed to (and not even auditing). Typically, it would actually take a package and three triggers to code without the AUTONOMOUS_TRANSACTION. This does not mean that we will use autonomous transactions to 'fix' mutating table errors any time we hit them - they must be used cautiously and with knowledge of how the transaction is really progressing. In the Caveats section later, we will explore the reasons for this. The mutating table error is actually for your protection; an understanding of why it happens is important. Do not fall into the trap of believing that autonomous transactions have removed mutating triggers as an issue!
This is a frequently asked question, 'How can I create a database object whenever I insert a row into such and such a table?' The database object varies from question to question. Sometimes people want to create a database USER when they insert into some table, sometimes they want to create a table or sequence. Since DDL always issues a commit right before and right after it executes (or a commit and a rollback depending on the success or failure of the DDL), doing DDL in a trigger was not possible. Now, autonomous transactions make this possible.
In the past, one might have used DBMS_JOB to schedule the DDL to execute after the transaction commits. This is still a viable option and in almost all cases is still the correct, optimal option. The nice thing about using DBMS_JOB to schedule the DDL is that it offers a way of making the DDL transactional. If the trigger queues a job to be executed, and that job creates a user account, upon rollback of the parent transaction, the job we queued to create the user will be rolled back as well. The row representing the job will be 'un-inserted'. No record in your PEOPLE table and no database account. Using autonomous transactions in the same scenario, you will have created the database account, but have no record in the PEOPLE table. The drawback to the DBMS_JOB approach is that there will necessarily be a small lag between the time you commit, and the time at which the job actually runs. The user would be created after you commit, soon after, but not immediately. Which method you use will be based upon your requirements. Again, in almost every case, the argument should be made for DBMS_JOB.
The example we will use to demonstrate doing DDL in triggers is the case where you want to CREATE a user in the database upon INSERT into a table and DROP that user upon DELETE. In this example below, I am going out of my way to avoid the condition where you could end up with a user created, but no row in the table or, upon a delete, be left with a record in the table, but no user account. My method is to use an INSTEAD OF TRIGGER on a view of the APPLICATION_USERS_TBL table. INSTEAD OF triggers are handy devices that allow us to provide the logic to be performed during the modification of rows in a view instead of the default processing Oracle would do. In Chapter 20 on Using Object Relational Features, we demonstrate how we can use INSTEAD OF triggers to allow for updates to complex views, which Oracle would not permit updates to otherwise. Here, we will use them to perform the act of creating a USER, and inserting the row into a real table (or dropping the user and deleting the row). This will ensure that either both the USER gets created and the row inserted, or neither take place. If the trigger was just on the table itself, we would not be able to ensure that either both, or neither took place - the view will allow us to link the two events together. Instead of inserting or deleting the real physical table, all applications will insert and delete from the view. The view will have an INSTEAD OF trigger on it, so it can procedurally process the changes row by row. In this fashion, I will be able to guarantee that if a row exists in the real table, the user account is created. If a row is removed from the real table, the user account is dropped. The example will show best how I accomplished this. I will point out the relevant parts as we get to them.
We will start by creating the schema that will hold this application:
tkyte@TKYTE816> create user demo_ddl identified by demo_ddl; User created. tkyte@TKYTE816> grant connect, resource to demo_ddl with admin option; Grant succeeded. tkyte@TKYTE816> grant create user to demo_ddl; Grant succeeded. tkyte@TKYTE816> grant drop user to demo_ddl; Grant succeeded. tkyte@TKYTE816> connect demo_ddl/demo_ddl demo_ddl@TKYTE816>
So, we have just created a user, and we want that user to grant CONNECT and RESOURCE to other users. (Note that CONNECT and RESOURCE are used for convenience here. You would use your own set of privileges as dictated by your needs.) Hence, we need to grant CONNECT and RESOURCE to this schema using the WITH ADMIN OPTION so the user can grant them to others. Additionally, since we want to create and drop users in the trigger, we must be granted the CREATE and DROP user privileges directly, as above. We need these grants to be directly to this schema, not via a role, since triggers always execute with definers rights and in that mode, roles are not enabled (see Chapter 23 on Invoker and Definer Rights for more information on this topic).
Next, we create the application table to hold our users. We will place a trigger on this table for the BEFORE INSERT or DELETE event. This trigger will be used to make sure no one ever inserts or deletes this table directly (including the owner). The reason is that we need all inserts/deletes to take place against the view so the DDL gets done as well.
In the code below, MY_CALLER is a small routine that I frequently use (along with the WHO_CALLED_ME routine). You can find the code for those routines in the Necessary Supplied Packages guide at the back of this book, in the section on DBMS_UTILITY. This function simply returns the name of the procedure/function/trigger that caused the code to execute. If MY_CALLER is not the trigger on the views (yet to be created), it will not allow you to perform this operation.
demo_ddl@TKYTE816> create table application_users_tbl 2 ( uname varchar2(30) primary key, 3 pw varchar2(30), 4 role_to_grant varchar2(4000) 5 ); Table created. demo_ddl@TKYTE816> create or replace trigger application_users_tbl_bid 2 before insert or delete on application_users_tbl 3 begin 4 if ( my_caller not in ( 'DEMO_DDL.APPLICATION_USERS_IOI', 5 'DEMO_DDL.APPLICATION_USERS_IOD' ) ) 6 then 7 raise_application_error(-20001, 'Cannot insert/delete directly'); 8 end if; 9 end; 10 / Trigger created.
Now we will create the view and INSTEAD OF trigger that does the actual work. We will place an INSTEAD OF INSERT trigger on this view to create the accounts. We will put an INSTEAD OF DELETE trigger on this view as well. The DELETE will cause a DROP USER statement to be executed. You could extend this to add support for INSTEAD OF UPDATE triggers to enable the addition of roles and changing of passwords via an UPDATE as well.
When the INSTEAD OF INSERT trigger fires, it will execute two statements:
A single statement similar to GRANT CONNECT, RESOURCE TO SOME_USERNAME IDENTIFIED BY SOME_PASSWORD.
An INSERT into the APPLICATION_USERS_TBL defined above.
The reason I used a GRANT, instead of CREATE USER and then GRANT, is that this statement performs a COMMIT, CREATE USER, GRANT, and COMMIT in one step. The advantage to this is that if the single statement above fails, we don't have to manually drop a user as we would if we used two statements to create and grant to the user. The CREATE USER statement might succeed and the GRANT could fail. We still need to catch errors, however, from the GRANT in order to delete the row we just inserted.
Since we do this INSERT and GRANT for each row inserted into the view, we can safely say that if a row exists in the real table, the account was successfully created, else it was not. There is still a very small window for potential failure, which we can never fully get rid of. If after we insert the row into the APPLICATION_USERS_TBL, the GRANT fails for some reason, and we are prevented from deleting the row we just inserted (due to the system crashing, or the tablespace with the APPLICATION_USERS_TBL going offline, and so on), we will have this inconsistency. Don't forget a GRANT is really a COMMIT/GRANT/COMMIT as all DDL is, so before the GRANT fails, it already committed the INSERT. The window is, however, sufficiently small to feel secure in this technique.
Now, let's implement the view, and the triggers on the view as described:
demo_ddl@TKYTE816> create or replace view 2 application_users 3 as 4 select * from application_users_tbl 5 / View created. demo_ddl@TKYTE816> create or replace trigger application_users_IOI 2 instead of insert on application_users 3 declare 4 pragma autonomous_transaction; 5 begin 6 insert into application_users_tbl 7 ( uname, pw, role_to_grant ) 8 values 9 ( upper(:new.uname), :new.pw, :new.role_to_grant ); 10 11 begin 12 execute immediate 13 'grant ' || :new.role_to_grant || 14 ' to ' || :new.uname || 15 ' identified by ' || :new.pw; 16 exception 17 when others then 18 delete from application_users_tbl 19 where uname = upper(:new.uname); 20 commit; 21 raise; 22 end; 23 end; 24 / Trigger created.
So, the INSTEAD OF INSERT trigger on this table first inserts a row into the APPLICATION_USERS_TBL. It then executes the GRANT to create the user. The GRANT is really COMMIT/GRANT/COMMIT so as soon as we execute it, the row in APPLICATION_USER_TBL is committed for us. If the GRANT succeeds, it has already committed the autonomous transaction, and the trigger exits. If on the other hand, the GRANT fails (the user already exists, invalid username, whatever), we catch the error, explicitly UNDO the insert, and commit that delete. We then re-raise the error.
We do the INSERT and then the DDL in this instance, because undoing the INSERT is much easier than undoing the user creation - I'd rather DELETE than DROP in order to undo work. In the end, this trigger ensures either we have a row in the APPLICATION_USERS_TBL and a user is created, or neither action takes place.
Now for the delete trigger to remove the row and drop the user:
demo_ddl@TKYTE816> create or replace trigger application_users_IOD 2 instead of delete on application_users 3 declare 4 pragma autonomous_transaction; 5 begin 6 execute immediate 'drop user ' || :old.uname; 7 delete from application_users_tbl 8 where uname = :old.uname; 9 commit; 10 end; 11 / Trigger created.
In this case, I've purposely reversed the order of operation. Here, we do DDL and then DML, whereas before we did DML then DDL. The reason is once again ease of error recovery. If the DROP USER fails, we have nothing to 'undo'. The probability of the DELETE failing is (hopefully) zero. We have no constraints that would make it so the row cannot be deleted. If there was a high probability that the DELETE could fail due to some integrity constraints, we might reverse the order of these operations, and make it look more like the INSTEAD OF INSERT trigger.
Now we can test it by inserting a user to create, checking that they are there, and then finally by 'deleting' the user.
demo_ddl@TKYTE816> select * from all_users where username = 'NEW_USER'; no rows selected demo_ddl@TKYTE816> insert into application_users values 2 ( 'new_user', 'pw', 'connect, resource' ); 1 row created. demo_ddl@TKYTE816> select * from all_users where username = 'NEW_USER'; USERNAME USER_ID CREATED ------------------------------ ---------- --------- NEW_USER 235 15-APR-01 demo_ddl@TKYTE816> delete from application_users where uname = 'NEW_USER'; 1 row deleted. demo_ddl@TKYTE816> select * from all_users where username = 'NEW_USER'; no rows selected
(Note the USER_ID you might see if you do this example on your own database will most likely be different to 235 as above. This is to be expected.) Lastly, we'll verify we cannot insert or delete from the 'real' table as well.
demo_ddl@TKYTE816> insert into application_users_tbl values 2 ( 'new_user', 'pw', 'connect, resource' ); insert into application_users_tbl values * ERROR at line 1: ORA-20001: Cannot insert/delete directly ORA-06512: at "DEMO_DDL.APPLICATION_USERS_TBL_BID", line 5 ORA-04088: error during execution of trigger 'DEMO_DDL.APPLICATION_USERS_TBL_BID' demo_ddl@TKYTE816> delete from application_users_tbl; delete from application_users_tbl * ERROR at line 1: ORA-20001: Cannot insert/delete directly ORA-06512: at "DEMO_DDL.APPLICATION_USERS_TBL_BID", line 5 ORA-04088: error during execution of trigger 'DEMO_DDL.APPLICATION_USERS_TBL_BID'
So there it is. The triggers are capable of adding and dropping users upon inserts and deletes from a database table. Using the INSTEAD OF triggers, we can make this 'safe' by providing compensating transactions when needed, to ensure our application database tables stay in sync with our DDL commands. You might even take this one step further and utilize database EVENT triggers that fire during the DROP of a user account, just to ensure that you do not have accounts being dropped without going through your view.
Oracle 7.1 introduced the ability to extend the SQL set of functions with any new function you could think of writing in PL/SQL. This is an extremely powerful feature, especially today, when these functions may be written in Java and C, in addition to PL/SQL. In the past, the one thing that all functions called from SQL must promise, is to Write No Database State (WNDS). If your function did an INSERT, UPDATE, DELETE, CREATE, ALTER, COMMIT, and so on, or called any function or procedure that performed on of these operations, it simply could not be called from SQL.
Using autonomous transactions, we can now write to the database state in functions called from SQL. There are few reasons for doing this, but two that I've seen in the past more than once are:
Really strict auditing. I want to know what data each person saw. I need to record the ID of each record they queried from the system.
My report generator only lets me run SQL SELECT statements. I really need to call a stored procedure that does some inserts from this report (to populate a parameter table for the report, perhaps).
Let's look at how each one might be implemented.
I have seen certain government settings where, for privacy reasons, they need to track who has seen various elements of any given record. For example, the tax office keeps very detailed records as to how much you make, what you own, and so on. This is extremely sensitive information. Whenever someone queries up someone's record and sees this sensitive information, they need to audit that. This is so they can audit over time to see if people are getting into records they should not be, or to retroactively find out who had access to certain information after a leak to the press, or some other exposure.
With autonomous transactions and views, we can do this in a way that is very non-intrusive and, to the casual end user using whatever tools, is totally transparent. They will not be able to get around it, and it will not get in their way. It will, of course, add additional overhead to the query, but this is really suited to those occasions where you pull up one record at a time, not hundreds or thousands of records. Given this constraint, the implementation is quite simple. Using the EMP table as a template, we can implement an audit on the HIREDATE, SALARY, and COMMISSION columns, so whenever someone views a SALARY for example, we know who looked at it, and even what record that they saw. We'll start by creating an audit trail table for our EMP table, which we copied from SCOTT previously in this chapter:
tkyte@TKYTE816> create table audit_trail 2 ( username varchar2(30), 3 pk number, 4 attribute varchar2(30), 5 dataum varchar2(255), 6 timestamp date 7 ) 8 / Table created.
Next, we'll create a series of overloaded functions in an audit trail package. These functions will each be passed the primary key value of the row being selected, as well as the column value and name of the column. We use overloaded functions so that dates would be preserved as dates, and numbers as numbers, allowing us to convert them into a standard format for storing in the character string DATAUM above:
tkyte@TKYTE816> create or replace package audit_trail_pkg 2 as 3 function record( p_pk in number, 4 p_attr in varchar2, 5 p_dataum in number ) return number; 6 function record( p_pk in number, 7 p_attr in varchar2, 8 p_dataum in varchar2 ) return varchar2; 9 function record( p_pk in number, 10 p_attr in varchar2, 11 p_dataum in date ) return date; 12 end; 13 / Package created.
So, now we are ready to implement the package body itself. Here each RECORD function above, calls the same internal procedure LOG. LOG is the autonomous transaction that inserts into the audit trail table, and commits. Notice in particular, how the date RECORD function below formats the date column into a string that preserves the time component for us:
tkyte@TKYTE816> create or replace package body audit_trail_pkg 2 as 3 4 procedure log( p_pk in number, 5 p_attr in varchar2, 6 p_dataum in varchar2 ) 7 as 8 pragma autonomous_transaction; 9 begin 10 insert into audit_trail values 11 ( user, p_pk, p_attr, p_dataum, sysdate ); 12 commit; 13 end; 14 15 function record( p_pk in number, 16 p_attr in varchar2, 17 p_dataum in number ) return number 18 is 19 begin 20 log( p_pk, p_attr, p_dataum ); 21 return p_dataum; 22 end; 23 24 function record( p_pk in number, 25 p_attr in varchar2, 26 p_dataum in varchar2 ) return varchar2 27 is 28 begin 29 log( p_pk, p_attr, p_dataum ); 30 return p_dataum; 31 end; 32 33 function record( p_pk in number, 34 p_attr in varchar2, 35 p_dataum in date ) return date 36 is 37 begin 38 log( p_pk, p_attr, 39 to_char(p_dataum,'dd-mon-yyyy hh24:mi:ss') ); 40 return p_dataum; 41 end; 42 43 end; 44 / Package body created. tkyte@TKYTE816> create or replace view emp_v 2 as 3 select empno , ename, job,mgr, 4 audit_trail_pkg.record( empno, 'sal', sal ) sal, 5 audit_trail_pkg.record( empno, 'comm', comm ) comm, 6 audit_trail_pkg.record( empno, 'hiredate', hiredate ) hiredate, 7 deptno 8 from emp 9 / View created.
So, what we have created is a view that exposes the three columns HIREDATE, SAL, and COMM via a PL/SQL function. The PL/SQL function is our audit function that will silently record who looked at what, and when. This view is suitable for direct 'lookup'-type queries such as the following:
tkyte@TKYTE816> select empno, ename, hiredate, sal, comm, job 2 from emp_v where ename = 'KING'; EMPNO ENAME HIREDATE SAL COMM JOB ---------- ---------- --------- ---------- ---------- --------- 7839 KING 17-NOV-81 5000 PRESIDENT tkyte@TKYTE816> column username format a8 tkyte@TKYTE816> column pk format 9999 tkyte@TKYTE816> column attribute format a8 tkyte@TKYTE816> column dataum format a20 tkyte@TKYTE816> select * from audit_trail; USERNAME PK ATTRIBUT DATAUM TIMESTAMP -------- ----- -------- -------------------- --------- TKYTE 7839 hiredate 17-nov-1981 00:00:00 15-APR-01 TKYTE 7839 sal 5000 15-APR-01 TKYTE 7839 comm 15-APR-01 tkyte@TKYTE816> select empno, ename from emp_v where ename = 'BLAKE'; EMPNO ENAME ---------- ---------- 7698 BLAKE tkyte@TKYTE816> select * from audit_trail; USERNAME PK ATTRIBUT DATAUM TIMESTAMP -------- ----- -------- -------------------- --------- TKYTE 7839 hiredate 17-nov-1981 00:00:00 15-APR-01 TKYTE 7839 sal 5000 15-APR-01 TKYTE 7839 comm 15-APR-01
As you can see from the above, I can tell that TKYTE viewed the HIREDATE, SAL, and COMM columns on the listed date. The second query did not retrieve information on these columns and therefore, no additional audit records were produced.
The reason I said the above view is appropriate for 'lookup'-type queries is because it will tend to 'over-audit' in some cases. There may be cases where it reports that someone looked at some piece of information, when in fact they did not actually see it. It was filtered later in a complex query, or it was aggregated up to some value not associated with a single individual. For example, the following shows that using an aggregate, or using a column in the WHERE clause, will cause this to be audited 'as seen'.
We start by clearing out the audit trail table; just to make it obvious what is going in:
tkyte@TKYTE816> delete from audit_trail; 3 rows deleted. tkyte@TKYTE816> commit; Commit complete. tkyte@TKYTE816> select avg(sal) from emp_v; AVG(SAL) ---------- 2077.14286 tkyte@TKYTE816> select * from audit_trail; USERNAME PK ATTRIBUT DATAUM TIMESTAMP -------- ----- -------- -------------------- --------- TKYTE 7499 sal 1600 15-APR-01 ... TKYTE 7934 sal 1300 15-APR-01 14 rows selected. tkyte@TKYTE816> select ename from emp_v where sal >= 5000; ENAME ---------- KING tkyte@TKYTE816> select * from audit_trail; USERNAME PK ATTRIBUT DATAUM TIMESTAMP -------- ----- -------- -------------------- --------- TKYTE 7499 sal 1600 15-APR-01 ... TKYTE 7934 sal 1300 15-APR-01 28 rows selected.
The aggregate query recorded each salary we 'looked' at in order to get the AVG(SAL). The WHERE SAL >= 5000 query similarly recorded each salary we looked at, in order to get the answer. There is no good solution for these cases, other than not to use this view to answer these types of questions. In the case of the AVG(SAL), you would want to expose only the SAL column, maybe other information, and use this view in your application when you needed the average salary, for example. That is, query a view that does not associate the SAL column with an individual, you can see the salaries, but not who the salaries belong to. The other question, SAL >= 5000, is hard to answer without recording each salary. For this I might use a stored procedure that returned a REF CURSOR. The stored procedure can safely query the EMP table using a predicate on SAL, but only select out other information, minus the SAL column. The user would not know how much the person made, only that it was above some value. You would restrict your usage of the EMP_V to the times when you wanted to show both the person-related information (EMPNO and ENAME) and SAL.
So in this context, running DML from SQL is of a very specialized use, and must be used cautiously.
This is a truly handy use of autonomous transactions in SQL statements. In many cases, people are using tools that only allow them to process SQL SELECT statements, or perhaps they can do INSERTs and such, but really need to call a stored procedure but they are unable to. Autonomous transactions make it so we can ultimately call any stored procedure or function using a SQL SELECT statement.
Let's say you've set up a stored procedure that puts some values into a table. It puts these values into this table so that a query run later in that session can restrict its values, based on the contents of that table. If this table is not populated, your report does not run. You are in an environment that does not permit you to run stored procedures, only 'regular' SQL. However, you really need to run this procedure. How can we do this? The following demonstrates how this would work:
tkyte@TKYTE816> create table report_parm_table 2 ( session_id number, 3 arg1 number, 4 arg2 date 5 ) 6 / Table created. tkyte@TKYTE816> create or replace 2 procedure set_up_report( p_arg1 in number, p_arg2 in date ) 3 as 4 begin 5 delete from report_parm_table 6 where session_id = sys_context('userenv','sessionid'); 7 8 insert into report_parm_table 9 ( session_id, arg1, arg2 ) 10 values 11 ( sys_context('userenv','sessionid'), p_arg1, p_arg2 ); 12 end; 13 / Procedure created.
So what we have here is an existing stored procedure that writes to the database state - it is part of an already instituted system. We would like to call it from a SQL SELECT statement, since this is the only method available to us. We will need to wrap this SET_UP_REPORT procedure in a small PL/SQL function, because the only thing SQL can call are functions. Additionally, we need the wrapper to supply the AUTONOMOUS_TRANSACTION pragma for us:
tkyte@TKYTE816> create or replace 2 function set_up_report_F( p_arg1 in number, p_arg2 in date ) 3 return number 4 as 5 pragma autonomous_transaction; 6 begin 7 set_up_report( p_arg1, p_arg2 ); 8 commit; 9 return 1; 10 exception 11 when others then 12 rollback; 13 return 0; 14 end; 15 / Function created. tkyte@TKYTE816> select set_up_report_F( 1, sysdate ) from dual 2 / SET_UP_REPORT_F(1,SYSDATE) -------------------------- 1 tkyte@TKYTE816> select * from report_parm_table 2
It might be interesting to see what would happen if we tried to call this function from SQL, without the autonomous transaction. If you recompile the above function with the pragma you would receive:
tkyte@TKYTE816> select set_up_report_F( 1, sysdate ) from dual 2 / select set_up_report_F( 1, sysdate ) from dual * ERROR at line 1: ORA-14552: cannot perform a DDL, commit or rollback inside a query or DML ORA-06512: at "TKYTE.SET_UP_REPORT_F", line 10 ORA-14551: cannot perform a DML operation inside a query ORA-06512: at line 1
This is exactly what the autonomous transaction is avoiding. So, we now have a function that can be called from SQL, and does an actual insert into a database table. It is important to note that the wrapper function must commit (or rollback), before returning to avoid the ORA-06519 error (see the Errors You Might Encounter section for more information) that would happen otherwise. Additionally, the function needs to return something - anything, but it has to return something; I am returning 1 for success, 0 for failure. Lastly, the important thing to note is that the function can only accept IN parameters - not IN/OUT or OUT. This is because the SQL layer will not permit parameters of this mode.
I would like to caveat this approach. Normally, I would do this at the end, but this directly applies to calling functions that modify the database from SQL. It can have dangerous side effects due to the way the database optimizes and executes queries. The above example was relatively 'safe'. DUAL is a single row table, we selected our function, and it should be called only once. There were no joins, no predicates, no sorts, and no side effects. This should be reliable. There are other cases where our function may be called less than we thought it should, more than we thought, or luckily, exactly as many times as we thought. In order to demonstrate this, I will use a somewhat contrived example. We will have a simple COUNTER table that an autonomous transaction will update with every call made to it. In this fashion, we can run queries, and see how many times our function is actually called:
tkyte@TKYTE816> create table counter ( x int ); Table created. tkyte@TKYTE816> insert into counter values (0); 1 row created. tkyte@TKYTE816> create or replace function f return number 2 as 3 pragma autonomous_transaction; 4 begin 5 update counter set x = x+1; 6 commit; 7 return 1; 8 end; 9 / Function created.
So, this is the function and COUNTER table. Every time F is called, X will be incremented by 1. Let's try it out:
tkyte@TKYTE816> select count(*) 2 from ( select f from emp ) 3 / COUNT(*) ---------- 14 tkyte@TKYTE816> select * from counter; X ---------- 0
Apparently, our function never got called. It looks like it should have been called 14 times but it was not. Just to show that F works we use the following:
tkyte@TKYTE816> select count(*) 2 from ( select f from emp union select f from emp ) 3 / COUNT(*) ---------- 1 tkyte@TKYTE816> select * from counter; X ---------- 28
This is what we expected. The function F was called 28 times - 14 times for each query in the UNION statement. Since a UNION does a SORT DISTINCT as a side effect of processing, the COUNT(*) from the union is 1 (this is correct) and the number of calls was 28, which is what we expected. What if we modify the query just a little, though:
tkyte@TKYTE816> update counter set x = 0; 1 row updated. tkyte@TKYTE816> commit; Commit complete. tkyte@TKYTE816> select f from emp union ALL select f from emp 2 / F ---------- 1 ... 1 28 rows selected. tkyte@TKYTE816> select * from counter; X ---------- 32
28 rows came back but our function was apparently called 32 times! Beware of side effects. Oracle never promised to either call your function (first example above) or call it a deterministic number of times (last example). Be extremely wary of using this functionality (writing to the database in a function called in SQL) when any table other than DUAL is involved, and you have joins, sorts, and so on. The results may be surprising.
Autonomous transactions also allow for the development of more modular code. Traditionally, one would write a series of packages that performed some operations. These operations would do some modifications in the database and then, depending on the outcome, either commit or roll them back. This is all well and good if your procedures are the only thing to be concerned with. In a large-scale application, however, it is rare that your simple package would be the only thing going on. It is most likely a small piece of a much larger pie.
In a typical procedure, if you commit, you commit not only your work, but also all of the outstanding work performed in your session before the procedure was called. By committing you are making permanent your work, and that other work. The problem is, that other work might not be 100 percent complete as yet. Therefore, your commit introduces the potential for an error in the invoking routine. It has lost the ability to roll back its changes in the event of a failure, and it might not even be aware of that.
Using autonomous transactions, you may now create self-contained transactions that take place without affecting the invoking transactions state. This could be extremely useful for many types of routines such as auditing, logging, and other services. It allows you to develop code that may be safely called from a variety of environments, all without effecting these environments in an adverse way. These are valid uses for autonomous transactions - auditing, logging, and other service-oriented routines. I, in general, do not believe in committing in a stored procedure except in cases such as those. I believe transaction control should be only in the hands of the client application. Care must be taken to ensure that you do not abuse autonomous transactions. If your code should be invoked as a logical part of a much larger transaction (for example, you are supplying the ADDRESS_UPDATE package in an HR system), then coding it as an autonomous transaction would not be appropriate. The invoker would like to be able to call your functionality, and other related packages, committing all of the work (or not) as a whole. So, if you had utilized an autonomous transaction, the invoker would lose this control, and building larger transactions from these smaller transactions would not be possible. Additionally, one of the attributes of an autonomous transaction is that it cannot see any of the uncommitted work performed by its caller. We'll hear more on that in the How They Work section. This would mean that your autonomous transaction would not be able to see the uncommitted updates to the rest of the HR information. You need to understand how your code will ultimately be used in order to utilize this functionality correctly.
This section will describe how autonomous transactions work, and what you can expect from them. We will investigate transactional control flow with regards to autonomous transactions. We will also see how autonomous transactions affect the scope of various elements such as packaged variables, session settings, database changes, and locks. We will explore the correct way to end an autonomous transaction, and finally wrap up with a section on savepoints.
The transaction control flow of an autonomous transaction begins with a BEGIN, and ends at the END. What I mean by this is that given the following block of code:
declare pragma autonomous_transaction; X number default func; (1) begin (2) ... end; (3)
the autonomous transaction begins at (2), not at (1). It begins with the first executable section. If FUNC is in fact a function that performs operations in the database, it is not part of the autonomous transaction! It will be part of the parent transaction. Additionally, the order of items in the DECLARE block is not relevant - the PRAGMA can come first or last. The entire DECLARE block is part of the parent transaction, not the autonomous transaction. An example will make this clear:
tkyte@TKYTE816> create table t ( msg varchar2(50) ); Table created. tkyte@TKYTE816> create or replace function func return number 2 as 3 begin 4 insert into t values 5 ( 'I was inserted by FUNC' ); 6 return 0; 7 end; 8 / Function created.
So, we have a function that does some work in the database. Let's call this function in the DECLARE block of an autonomous transaction now:
tkyte@TKYTE816> declare 2 x number default func; 3 pragma autonomous_transaction; 4 begin 5 insert into t values 6 ( 'I was inserted by anon block' ); 7 commit; 8 end; 9 / PL/SQL procedure successfully completed. tkyte@TKYTE816> select * from t; MSG -------------------------------------------------- I was inserted by FUNC I was inserted by anon block
Right now, both rows are there. However, one of the rows has yet to be committed. We can observe this by rolling back:
tkyte@TKYTE816> rollback; Rollback complete. tkyte@TKYTE816> select * from t; MSG -------------------------------------------------- I was inserted by anon block
As you can see, after executing the anonymous block, it appears that both rows are in table T, and committed. This is misleading however. The row inserted by the function is in fact, still outstanding. It is part of the parent transaction, and is still uncommitted. By rolling back, we can see that it goes away, but the row inserted in the autonomous transaction remains as expected.
So, an autonomous transaction begins at the very next BEGIN after the PRAGMA, and is in effect for the entire time that BEGIN block is still in scope. Any functions or procedures that the autonomous transaction calls, any triggers that it causes to fire, and so on are part of its autonomous transaction, and will commit or be rolled back along with it.
Autonomous transactions can be nested, so that one can cause another to occur. These new autonomous transactions behave in exactly the same fashion as the parent autonomous transaction - they begin with the first BEGIN, they have transactional control until the end statement is reached, and they are totally independent of their parent transaction. The only limit to the depth of nesting of autonomous transactions is the init.ora parameter TRANSACTIONS, which governs the total number of concurrent transactions possible in the server at the same time. Normally, this defaults to 1.1 times the number of SESSIONS, and if you plan on using lots of autonomous transactions, you may have to increase this parameter.
By scope, I mean the ability to see values of various things within the database. We are concerned with four different elements here. We will look at the scope of:
Packaged variables.
Session settings/parameters.
Database changes.
Locks.
and consider each in turn.
An autonomous transaction creates a new transaction state but not a new 'session'. Therefore, any variables that are in the scope (are visible) of both the parent and the autonomous transaction, will be identical in nature to both, since variable assignment is not covered by transactional boundaries (you cannot rollback a PL/SQL assignment to a variable). So, not only can an autonomous transaction see the parent transaction's variable state, but it can also modify it, and the parent will see these changes.
What this means is that changes to variables, since they are explicitly not affected by commits and rollbacks, fall outside of the domain of the autonomous transaction, and will behave exactly as they would in the absence of autonomous transactions. In way of a simple example to demonstrate this, I'll create a package that has a global variable. The 'parent transaction' (our session) will set this value to some known state, and an autonomous transaction will then modify it. The parent transaction will see the effects of that modification:
tkyte@TKYTE816> create or replace package global_variables 2 as 3 x number; 4 end; 5 / Package created. tkyte@TKYTE816> begin 2 global_variables.x := 5; 3 end; 4 / PL/SQL procedure successfully completed. tkyte@TKYTE816> declare 2 pragma autonomous_transaction; 3 begin 4 global_variables.x := 10; 5 commit; 6 end; 7 / PL/SQL procedure successfully completed. tkyte@TKYTE816> set serveroutput on tkyte@TKYTE816> exec dbms_output.put_line( global_variables.x ); 10 PL/SQL procedure successfully completed.
This change to the global variable by the autonomous transaction will be in place regardless of the ultimate outcome of the autonomous transaction.
Again, since autonomous transactions create a new transaction but not a new session, the session state of the parent transaction is the same as the session state of the child. They both share the same exact session, but they just are running in separate transactions. The session is established when the application connected to the database. An autonomous transaction does not 'reconnect' to the database again, it just shares the same connection or session. Therefore, any session-level changes made in the parent will be visible to the child and furthermore, if the child makes any session-level changes via the ALTER SESSION command, these changes will be in effect for the parent transaction as well. It should be noted that the SET TRANSACTION command, which by definition works at the transaction-level, affects only the transaction in which it was issued. So for example, an autonomous transaction that issues a SET TRANSACTION USE ROLLBACK SEGMENT command will set the rollback segment only for its transaction, not for the parent. An autonomous transaction that issues SET TRANSACTION ISOLATION LEVEL SERIALIZABLE affects only its transaction, but an autonomous transaction that issues an ALTER SESSION SET ISOLATION_LEVEL=SERIALIZABLE will change the parent's isolation level, for their next transaction. Additionally, a parent READ ONLY transaction can invoke an autonomous transaction that modifies the database. The autonomous transaction is not forced to be read-only as well.
Now, this is where things start to 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 transaction depending on its isolation level.
I said before though, that this is where 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 these uncommitted changes, but a cursor opened by the parent and fetched from by the child, will. The following case shows how this works. We will recreate our EMP table (it has all kinds of auditing routines on it), and then code a package that modifies it, and prints it out. In this package, we'll have a global cursor that selects from EMP. There will be a single autonomous transaction. It simply fetches from a cursor and prints the results. It'll check first to see if the cursor is opened, and if not, it will open it. This will show us the difference in results we get, depending on who opened a given cursor. The cursor's resultset is always consistent with respect to the point in time it was opened, and the transaction it was opened in:
tkyte@TKYTE816> drop table emp; Table dropped. tkyte@TKYTE816> create table emp as select * from scott.emp; Table created. tkyte@TKYTE816> create or replace package my_pkg 2 as 3 4 procedure run; 5 6 end; 7 / Package created. tkyte@TKYTE816> create or replace package body my_pkg 2 as 3 4 5 cursor global_cursor is select ename from emp; 6 7 8 procedure show_results 9 is 10 pragma autonomous_transaction; 11 l_ename emp.ename%type; 12 begin 13 if ( global_cursor%isopen ) 14 then 15 dbms_output.put_line( 'NOT already opened cursor' ); 16 else 17 dbms_output.put_line( 'Already opened' ); 18 open global_cursor; 19 end if; 20 21 loop 22 fetch global_cursor into l_ename; 23 exit when global_cursor%notfound; 24 dbms_output.put_line( l_ename ); 25 end loop; 26 close global_cursor; 27 end; 28 29 30 procedure run 31 is 32 begin 33 update emp set ename = 'x'; 34 35 open global_cursor; 36 show_results; 37 38 show_results; 39 40 rollback; 41 end; 42 43 end; 44 / Package body created. tkyte@TKYTE816> exec my_pkg.run NOT already opened cursor x ... x Already opened SMITH ... MILLER PL/SQL procedure successfully completed.
When the cursor is opened in the parent's transaction state, the autonomous transaction can see these uncommitted rows - they were all x. The cursor opened in the autonomous transaction might as well have been opened in another session all together when it comes to this uncommitted data. It will never be able to see these uncommitted rows. We see the images of the data as they existed before the update took place.
So, this shows how a child autonomous transaction will react to uncommitted changes made by the parent as far as SELECTs go. What about the parent with regards to seeing data changes, made by the child? Well, this will depend on the parent's isolation level. If you use the default isolation level of READ COMMITTED, the parent will be able to see the changes. If you are using SERIALIZABLE transactions however, you will not be able to see the changes made, even though you made them. For example:
tkyte@TKYTE816> create table t ( msg varchar2(4000) ); Table created. tkyte@TKYTE816> create or replace procedure auto_proc 2 as 3 pragma autonomous_transaction; 4 begin 5 insert into t values ( 'A row for you' ); 6 commit; 7 end; 8 / Procedure created. tkyte@TKYTE816> create or replace 2 procedure proc( read_committed in boolean ) 3 as 4 begin 5 if ( read_committed ) then 6 set transaction isolation level read committed; 7 else 8 set transaction isolation level serializable; 9 end if; 10 11 auto_proc; 12 13 dbms_output.put_line( '--------' ); .14 for x in ( select * from t ) loop 15 dbms_output.put_line( x.msg ); 16 end loop; 17 dbms_output.put_line( '--------' ); 18 commit; 19 end; 20 / Procedure created. tkyte@TKYTE816> exec proc( TRUE ) -------- A row for you -------- PL/SQL procedure successfully completed. tkyte@TKYTE816> delete from t; 1 row deleted. tkyte@TKYTE816> commit; Commit complete. tkyte@TKYTE816> exec proc( FALSE ) -------- -------- PL/SQL procedure successfully completed.
As you can see, when the procedure is run in READ COMMITTED mode, we see the committed changes. When run in SERIALIZABLE mode, we cannot see the changes. This is because the changes in the autonomous transaction happened in another transaction all together, and the isolation mode of SERIALIZABLE dictates that we could only see our transactions changes (it is as if our transaction was the only transaction in the database in this mode, we are not permitted to see others' changes).
In the previous section, we explored what happens with regards to a child autonomous transaction reading a parent''s committed and uncommitted changes, as well as a parent reading a child autonomous transaction's changes. Now we will look at what happens with regards to locks.
Since the parent and child have two totally different transactions, they will not be able to share locks in any way shape or form. If the parent transaction has a resource locked that the child autonomous transaction also needs to lock, you will deadlock yourself. The following demonstrates this issue:
tkyte@TKYTE816> create or replace procedure child 2 as 3 pragma autonomous_transaction; 4 l_ename emp.ename%type; 5 begin 6 select ename into l_ename 7 from emp 8 where ename = 'KING' 9 FOR UPDATE; 10 commit; 11 end; 12 / Procedure created. tkyte@TKYTE816> create or replace procedure parent 2 as 3 l_ename emp.ename%type; 4 begin 5 select ename into l_ename 6 from emp 7 where ename = 'KING' 8 FOR UPDATE; 9 child; 10 commit; 11 end; 12 / Procedure created. tkyte@TKYTE816> exec parent BEGIN parent; END; * ERROR at line 1: ORA-00060: deadlock detected while waiting for resource ORA-06512: at "TKYTE.CHILD", line 6 ORA-06512: at "TKYTE.PARENT", line 9 ORA-06512: at line 1
Care must be taken to avoid a child deadlocking with its parent. The child will always 'lose' in this case, and the offending statement will be rolled back.
To end the autonomous transaction, we must always issue a full-blown COMMIT or ROLLBACK, or execute DDL, which does a COMMIT for us. The autonomous transaction itself will start automatically when the autonomous transaction makes any database changes, locks resources, or issues transaction control statements such as SET TRANSACTION or SAVEPOINT. The autonomous transaction must be explicitly terminated before control returns to the parent transaction (else an error will occur). A ROLLBACK to SAVEPOINT is not sufficient, even if this leaves no outstanding work, as it does not terminate the transaction state.
If an autonomous transaction exits 'normally' (not via a propagated exception), and neglects to COMMIT or ROLLBACK, it will receive the following error:
tkyte@TKYTE816> create or replace procedure child 2 as 3 pragma autonomous_transaction; 4 l_ename emp.ename%type; 5 begin 6 select ename into l_ename 7 from emp 8 where ename = 'KING' 9 FOR UPDATE; 10 end; 11 / Procedure created. tkyte@TKYTE816> exec child BEGIN child; END; * ERROR at line 1: ORA-06519: active autonomous transaction detected and rolled back ORA-06512: at "TKYTE.CHILD", line 6 ORA-06512: at line 1
So, just as an autonomous transaction must take care to avoid deadlocks with the parent transaction, it must also take care to cleanly terminate any transaction it begins (to avoid having it rolled back).
In Chapter 4 on Transactions, we described savepoints, and how they affect transactions in your application. Savepoints are scoped to the current transaction only. That is, an autonomous transaction cannot rollback to a savepoint issued in the calling routine's transaction. This savepoint just does not exist in the autonomous transaction's environment. Consider what happens if we try:
tkyte@TKYTE816> create or replace procedure child 2 as 3 pragma autonomous_transaction; 4 l_ename emp.ename%type; 5 begin 6 7 update emp set ename = 'y' where ename = 'BLAKE'; 8 rollback to Parent_Savepoint; 9 commit; 10 end; 11 / Procedure created. tkyte@TKYTE816> create or replace procedure parent 2 as 3 l_ename emp.ename%type; 4 begin 5 savepoint Parent_Savepoint; 6 update emp set ename = 'x' where ename = 'KING'; 7 8 child; 9 rollback; 10 end; 11 / Procedure created. tkyte@TKYTE816> exec parent BEGIN parent; END; * ERROR at line 1: ORA-01086: savepoint 'PARENT_SAVEPOINT' never established ORA-06512: at "TKYTE.CHILD", line 8 ORA-06512: at "TKYTE.PARENT", line 8 ORA-06512: at line 1
As far as the autonomous transaction was concerned, this savepoint never had been issued. If we remove the autonomous transaction from child above and re-execute, it works just fine. The autonomous transaction cannot affect the calling transaction's 'state'.
This does not mean that autonomous transactions cannot use savepoints - they can. They have to just use their own savepoints. For example, the following code demonstrates that a savepoint issued in the child transaction works. The one update inside the savepoint was rolled back as expected and the other persisted:
tkyte@TKYTE816> create or replace procedure child 2 as 3 pragma autonomous_transaction; 4 l_ename emp.ename%type; 5 begin 6 7 update emp set ename = 'y' where ename = 'BLAKE'; 8 savepoint child_savepoint; 9 update emp set ename = 'z' where ename = 'SMITH'; 10 rollback to child_savepoint; 11 commit; 12 end; 13 / Procedure created. tkyte@TKYTE816> create or replace procedure parent 2 as 3 l_ename emp.ename%type; 4 begin 5 savepoint Parent_Savepoint; 6 update emp set ename = 'x' where ename = 'KING'; 7 8 child; 9 commit; 10 end; 11 / Procedure created. tkyte@TKYTE816> select ename 2 from emp 3 where ename in ( 'x', 'y', 'z', 'BLAKE', 'SMITH', 'KING' ); ENAME ---------- SMITH BLAKE KING tkyte@TKYTE816> exec parent PL/SQL procedure successfully completed. tkyte@TKYTE816> select ename 2 from emp 3 where ename in ( 'x', 'y', 'z', 'BLAKE', 'SMITH', 'KING' ); ENAME ---------- SMITH y x
As with any feature, there are some nuances that need to be noted in the way this feature functions. This section attempts to address them each in turn. We will look at features that are mutually exclusive with autonomous transactions, the environments that may use them, differences in behavior you will notice using them, and other such issues.
Currently (at least up to Oracle 8.1.7), it is not feasible to use autonomous transactions in a distributed transaction. You will not receive a clear error message with regards to this. Rather, an internal error will be raised in various (but not all) cases. It is planned that autonomous transactions can be used in distributed transactions safely in the future. For now, if you are using a Database Link, do not use an autonomous transaction.
Autonomous transactions are available with PL/SQL only. They can be extended to Java, and other languages, by invoking the Java, or other language routine, from a PL/SQL block that is an autonomous transaction. So, if you need a Java stored procedure to be invoked as an autonomous transaction, you must create a stored procedure in PL/SQL that is an autonomous transaction and call the Java from that.
If an autonomous transaction exits in error, due to an exception that was not caught and handled, it's entire transaction, not just the offending statement, is rolled back. What this means is that a call to an autonomous transaction is an 'all-or-nothing' event. It either exits successfully having saved all of its work, or it exits with an exception and all of its uncommitted work is undone. Note that I stressed uncommitted in that sentence. An autonomous transaction can in fact commit many times during its execution, only its uncommitted work is rolled back. Normally, if a procedure exits with an exception, and you catch and handle that exception, it's uncommitted work is preserved - not so with an autonomous transaction. For example:
tkyte@TKYTE816> create table t ( msg varchar2(25) ); Table created. tkyte@TKYTE816> create or replace procedure auto_proc 2 as 3 pragma AUTONOMOUS_TRANSACTION; 4 x number; 5 begin 6 insert into t values ('AutoProc'); 7 x := 'a'; -- This will fail 8 commit; 9 end; 10 / Procedure created. tkyte@TKYTE816> create or replace procedure Regular_Proc 2 as 3 x number; 4 begin 5 insert into t values ('RegularProc'); 6 x := 'a'; -- This will fail 7 commit; 8 end; 9 / Procedure created. tkyte@TKYTE816> set serveroutput on tkyte@TKYTE816> begin 2 insert into t values ('Anonymous'); 3 auto_proc; 4 exception 5 when others then 6 dbms_output.put_line( 'Caught Error:' ); 7 dbms_output.put_line( sqlerrm ); 8 commit; 9 end; 10 / Caught Error: ORA-06502: PL/SQL: numeric or value error: character to number conversion error PL/SQL procedure successfully completed. tkyte@TKYTE816> select * from t; MSG ------------------------- Anonymous
Only the anonymous block's data is preserved. Contrast this to a 'regular' block's behavior:
tkyte@TKYTE816> delete from t; 1 row deleted. tkyte@TKYTE816> commit; Commit complete. tkyte@TKYTE816> begin 2 insert into t values ('Anonymous'); 3 regular_proc; 4 exception 5 when others then 6 dbms_output.put_line( 'Caught Error:' ); 7 dbms_output.put_line( sqlerrm ); 8 commit; 9 end; 10 / Caught Error: ORA-06502: PL/SQL: numeric or value error: character to number conversion error PL/SQL procedure successfully completed. tkyte@TKYTE816> select * from t; MSG ------------------------- Anonymous RegularProc
Here, since we caught and handled the error, the rows from both the failed procedure and the anonymous block survived.
What this means in the end is that you cannot just slap PRAGMA AUTONOMOUS_TRANSACTION onto existing stored procedures, and expect the same behavior from them. There will be subtle differences.
If you are using GLOBAL TEMPORARY tables, one thing you must be aware of is the fact that a transaction-level temporary table cannot be used by more than one transaction, in a single session, at the same time. Temporary tables are managed at the session-level, and when they are created in the mode that makes them 'transactional' (on commit, delete rows), they can only be used by either the parent, or the child transaction, but not both. For example, the following shows that an autonomous transaction, which attempts to read or write a transaction-level temporary table that is already in use in the session, will fail:
tkyte@TKYTE816> create global temporary table temp 2 ( x int ) 3 on commit delete rows 4 / Table created. tkyte@TKYTE816> create or replace procedure auto_proc1 2 as 3 pragma autonomous_transaction; 4 begin 5 insert into temp values ( 1 ); 6 commit; 7 end; 8 / Procedure created. tkyte@TKYTE816> create or replace procedure auto_proc2 2 as 3 pragma autonomous_transaction; 4 begin 5 for x in ( select * from temp ) 6 loop 7 null; 8 end loop; 9 commit; 10 end; 11 / Procedure created. tkyte@TKYTE816> insert into temp values ( 2 ); 1 row created. tkyte@TKYTE816> exec auto_proc1; BEGIN auto_proc1; END; * ERROR at line 1: ORA-14450: attempt to access a transactional temp table already in use ORA-06512: at "TKYTE.AUTO_PROC1", line 5 ORA-06512: at line 1 tkyte@TKYTE816> exec auto_proc2; BEGIN auto_proc2; END; * ERROR at line 1: ORA-14450: attempt to access a transactional temp table already in use ORA-06512: at "TKYTE.AUTO_PROC2", line 5 ORA-06512: at line 1
This is the error you will get if you attempt to use the same temporary table by both transactions. It should be noted that this only happens with simultaneous transactions in the same session. Many concurrent transactions can, and do, use transaction-level temporary tables simultaneously when each transaction is owned by a separate session.
At first glance, autonomous transactions look like the answer to all of your mutating table problems. They might only be the beginning of a new set of logic problems however.
Let's say you wanted to enforce a rule that the average salary of all employees cannot be less than half of the maximum salary for anyone in their department. You might start with a procedure and trigger that looks like:
tkyte@TKYTE816> create or replace 2 procedure sal_check( p_deptno in number ) 3 is 4 avg_sal number; 5 max_sal number; 6 begin 7 select avg(sal), max(sal) 8 into avg_sal, max_sal 9 from emp 10 where deptno = p_deptno; 11 12 if ( max_sal/2 > avg_sal ) 13 then 14 raise_application_error(-20001,'Rule violated'); 15 end if; 16 end; 17 / Procedure created. tkyte@TKYTE816> create or replace trigger sal_trigger 2 after insert or update or delete on emp 3 for each row 4 begin 5 if (inserting or updating) then 6 sal_check(:new.deptno); 7 end if; 8 9 if (updating or deleting) then 10 sal_check(:old.deptno); 11 end if; 12 end; 13 / Trigger created. tkyte@TKYTE816> tkyte@TKYTE816> update emp set sal = sal*1.1; update emp set sal = sal*1.1 * ERROR at line 1: ORA-04091: table TKYTE.EMP is mutating, trigger/function may not see it ORA-06512: at "TKYTE.SAL_CHECK", line 6 ORA-06512: at "TKYTE.SAL_TRIGGER", line 3 ORA-04088: error during execution of trigger 'TKYTE.SAL_TRIGGER'
This didn't work too well. We hit the mutating table error right away because we quite simply cannot read the table that we are in the process of modifying. So, we immediately think 'mutating tables equals autonomous transactions', and apply an autonomous transaction to our procedure:
tkyte@TKYTE816> create or replace 2 procedure sal_check( p_deptno in number ) 3 is 4 pragma autonomous_transaction; 5 avg_sal number; 6 max_sal number; 7 begin ... Procedure created.
and sure enough, it appears to have fixed the issue:
tkyte@TKYTE816> update emp set sal = sal*1.1; 14 rows updated. tkyte@TKYTE816> commit; Commit complete.
Upon closer inspection though, we find that we have a fatal flaw in our design. During testing we found that could easily happen:
tkyte@TKYTE816> update emp set sal = 99999.99 where ename = 'WARD'; 1 row updated. tkyte@TKYTE816> commit; Commit complete. tkyte@TKYTE816> exec sal_check(30); BEGIN sal_check(30); END; * ERROR at line 1: ORA-20001: Rule violated ORA-06512: at "TKYTE.SAL_CHECK", line 14 ORA-06512: at line 1
I updated WARD with a very high salary; WARD works in department 30, and his salary is now very much higher than half of the average salary in that department. The trigger did not detect this, but after the fact, running the same code, the trigger does let us see that the rule was violated. Why? Because our autonomous transaction cannot see any of the changes we are making. Hence, the update of the salary to a large amount appears OK, because the procedure is validating the table, as it existed before our update began! It would be the next unlucky end user who would trigger this violation (as we artificially forced by running the SAL_CHECK procedure).
Any time you use an autonomous transaction to avoid a mutating table, you must make sure you are doing the right thing. In the Auditing that Can Not be Rolled Back example, I used an autonomous transaction in a 'safe' way. The logic of my trigger is not affected by the fact that I am seeing the table as it existed before the transaction took place. In this example above, my trigger is affected greatly by this fact. Special care must be taken, and every trigger that uses an autonomous transaction should be verified for correctness.
There are a few errors you might expect to encounter with autonomous transactions. They are listed here for completeness, but we have already seen each of them in the above examples.
// *Cause: Before returning from an autonomous PL/SQL block, all autonomous // transactions started within the block must be completed (either // committed or rolled back). If not, the active autonomous // transaction is implicitly rolled back and this error is raised. // *Action: Ensure that before returning from an autonomous PL/SQL block, // any active autonomous transactions are explicitly committed // or rolled back.
You will receive this error any time you exit an autonomous transaction, and neglect to either commit or roll it back yourself. The action taken will be to roll back your autonomous transaction and propagate this error to the invoker. You should always ensure that all exit paths from your autonomous procedures either commit or rollback, to avoid this issue altogether. This error is always the result of an error in the logic of your code.
// *Cause: An attempt was made to access a transactional temporary table // that has been already populated by a concurrent transaction of // the same session. // *Action: do not attempt to access the temporary table until the // concurrent transaction has committed or aborted.
As demonstrated above, a global temporary table created with ON COMMIT DELETE ROWS may be utilized by exactly one transaction in any given session. Care must be taken to not have both a parent and child transaction attempt to utilize the same temporary table.
// *Cause: Transactions deadlocked one another while waiting for resources. // *Action: Look at the trace file to see the transactions and resources // involved. Retry if necessary.
This is not really an autonomous transaction error, but I've included it here due to the increased probability of hitting this particular error when using them. Since the parent transaction is suspended during the execution of the child transaction, and will not be able to resume processing until the child transaction completes, a deadlock that would not occur if two concurrently executing sessions were used may very well occur when using autonomous transactions. It will occur when we attempt to update the same data from two separate transactions in a single session. Care must be taken to ensure that the child does not attempt to lock the same resources the parent might have locked already.
In this chapter we thoroughly explored the feature of autonomous transactions. We have seen how they can be used to generate more modular, safe code. We have seen how they can be used to do things that have previously not been possible, such as performing DDL in a trigger or running any stored function via a SELECT statement, regardless of whether that function wrote to the database or not. We also saw that it is not wise to think you know exactly how many times a function called from SQL will actually be called, so be careful when writing to the database state in that fashion. We have seen how this feature can be used to avoid a mutating table error, as well as how this feature might lead to the 'wrong' result when used incorrectly to solve this problem.
Autonomous transactions are a powerful feature that Oracle itself has been using for years in the guise of recursive SQL. It is now available for you to use in your applications as well. A thorough understanding of transactions, how they work, where they start, and when they end, is mandatory before utilizing this feature, as various side effects can occur. For example, a session can deadlock itself, a parent transaction may or may not see the results of the child autonomous transaction, a child autonomous transaction cannot see outstanding work of the parent, and so on.