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

202
CHAPTER 6 ■ LOCKING AND LATCHING
6 resource_busy exception;
7 pragma exception_init( resource_busy, -54 );
8 begin
9 l_lock_id :=
10 dbms_utility.get_hash_value( to_char( :new.x ), 0, 1024 );
11 if ( dbms_lock.request
12 ( id => l_lock_id,
13 lockmode => dbms_lock.x_mode,
14 timeout => 0,
15 release_on_commit => TRUE ) 0 )
16 then
17 raise resource_busy;
18 end if;
19 end;
20 /
Trigger created.
Now, if in two separate sessions we execute the following:
scott@ORA10G> insert into demo values ( 1 );
1 row created.
it will succeed in the first session but immediately issue the following in the second session:
scott@ORA10G> insert into demo values ( 1 );
insert into demo values ( 1 )
*
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified
ORA-06512: at "SCOTT.DEMO_BIFER", line 14
ORA-04088: error during execution of trigger 'SCOTT.DEMO_BIFER'
The concept here is to take the supplied primary key value of the table protected by the
trigger and put it in a character string. We can then use DBMS_UTILITY.GET_HASH_VALUE to come
up with a “mostly unique” hash value for the string. As long as we use a hash table smaller
than 1,073,741,823, we can “lock” that value exclusively using DBMS_LOCK.
After hashing, we take that value and use DBMS_LOCK to request that lock ID to be exclusively
locked with a timeout of ZERO (this returns immediately if someone else has locked that
value). If we timeout or fail for any reason, we raise ORA-54 Resource Busy. Otherwise, we do
nothing—it is OK to insert, we won’t block.
Of course, if the primary key of your table is an INTEGER and you don’t expect the key to go
over 1 billion, you can skip the hash and just use the number as the lock ID.
You’ll need to play with the size of the hash table (1,024 in this example) to avoid artificial
resource busy messages due to different strings hashing to the same number. The size of the
hash table will be application (data)-specific, and it will be influenced by the number of concurrent
insertions as well. Lastly, bear in mind that although Oracle has unlimited row-level
locking, it has a finite number of enqueue locks. If you insert lots of rows this way without
committing in your session, then you might find that you create so many enqueue locks that
you exhaust the system of enqueue resources (you exceed the maximum value set in the