Exclusive access to a stored procedure

Question

Hi all,
I've the following question:
Is it possible to set an exclusive access for sessions to a procedure in the DB?
So if session A enters the procedure and runs for example a loop or something like that and then session B comes and needs to enter the same procedure, it has to wait till session A finished and left the procedure.
If it is possible, how?
Thanks in advance.

Answer 1

> If it is possible, how?
It is called serialisation - forcing a resource (a procedure in your case) to service only a single caller at a time.
The means used to protect a resource to (for example) force serialisation is called a semaphore. There are numerous technical definitions for a semaphore. But they all imply the same thing. Apple calls it "A programming technique for coordinating activities in which multiple processes compete for the same kernel resources."
In Oracle, you can typically do this using DBMS_LOCK (as already stated). However, DBMS_LOCK is classified as a system procedure and by default, user/app schemas should not have access to it.
There is a very easy alternative to DBMS_LOCK - using Oracle's own default row locking.
This approach works in the following fashiion.
You create a dummy table (it will never contain any committed rows and only serve as the "semaphore device").
create table semaphore( id number primary key ) organization index;
To force serialisation, the very first step in the procedure is to insert a row into this table using a unique id for that procedure. E.g.
insert into semaphore values( UNIQUE_ID_FOR_MY_PROC );
A second (or 3rd/4th/etc) copy of the procedure will be blocked on its INSERT. It will wait for the 1st INSERT to be either committed or rolled back.
The procedure does its thing. Right at the end, it issues a:
delete from semaphore where id = UNIQUE_ID_FOR_MY_PROC;
This will still block the 2nd copy of the procedure. As soon as the 1st process now issue a COMMIT, the 2nd copy will continue and it will insert successfully into the SEMAPHORE table.
What I like about this approach is that any failure in the procedure, will result in ROLLBACK (either implicitly or explicitly). The ROLLBACK will remove the INSERT on the SEMAPHORE table and the 2nd copy of the procedure will now be able to continue.
Of course, it make sense not to do the INSERT and DELETE manually against the SEMAPHORE table, but instead use a PL/SQL package that does this for you. This way you have a nice wrapper API that can be extended to include more features.