This solution is used for telecom operator to dynamically extract exclusive number lists for concurrent customers to pick their number without conflict. This solution harnesses the inherent row-level lock machnism featured in morden Relational DB.

1. A Green Solution
that fixed a real-life Race Condition problem
by Kai Zhou
1

2. Problem
Production system now lacks functionality to provide concurrent customers
assuredly different set of numbers for their number selection.
So there might be confliction that if two or more customers both have chosen
number N within a same time span which is considerably short, any customer
might fail to order the number N because it may have been assigned to
another customer a moment ago.
Requirement
Improve “Get Available Number List” service module, make it return different
number-lists when it is called concurrently so that any certain number will not
be presented in more than one returned number-lists within a short time
span which can be defined as lock period.
2

3. Solution
The solution uses RDBMS’ inherent features such as
• Row Level Lock;
• Primary Key constraint
to resolve the problem described above.
An Oracle PL/SQL implementation is presented in later slides. The same logic
can also be written in other languages such as Pro*c, Java etc with the SQL.
And the final delivery can be a C library or a Web Services etc., depends on
the tech circumstances where the solution is implemented.
3

4. this slide unless you have read the script from following slides and want
to have a test
TEST
Take the following steps:
1) Create table available_phone_number_pool ( phone_number numeric(10) primary
key ) ; then insert 1000 records into it.
---- This table will mock the existing table in the production system that contains
available phone numbers.
2) Create table phone_number_selection_history ( phone_number numeric(10)
primary key, last_lock_time datetime)
---- This is the new table introduced to the production to help with the solution.
3) Use SQL*Plus to run the script concurrently multiple times from different terminal and
observe the screen output of their execution.
4

5. /* The Script -- non-conflict number selection */
set serveroutput on size 1000000
var v_c number
declare
cursor c_get_number_selection_list is
select num_pool.phone_number, num_select.last_lock_time
from available_phone_number_pool num_pool,
phone_number_selection_history num_select
where num_pool.phone_number=num_select.phone_number (+)
and (
num_select.last_lock_time is null
or
num_select.last_lock_time < sysdate - 10/(60*24)
);
v_rec c_get_number_selection_list%rowtype;
v_count int;
5
/* To be continued */
Implementation

6. begin
dbms_output.put_line('hellow world!');
v_count:=0;
open c_get_number_selection_list;
loop
<<next>>
fetch c_get_number_selection_list into v_rec;
if c_get_number_selection_list%notfound then
goto out;
end if;
if v_rec.last_lock_time is null then
begin
insert into phone_number_selection_history
values ( v_rec.phone_number, sysdate );
exception
when DUP_VAL_ON_INDEX then
dbms_output.put_line(‘Number ‘ ||v_rec.phone_number ||‘ is skipped ');
goto next;
end;
dbms_output.put_line(‘Number '|| v_rec.phone_number || ‘ is available’);
commit;
v_count:=v_count+1;
/* to be continued */ 6

7. else
begin
update phone_number_selection_history
set last_lock_time= sysdate
where phone_number= v_rec.phone_number
and last_lock_time < sysdate - 10/(60*24) ;
exception
when NO_DATA_FOUND then
dbms_output.put_line (‘Number '|| v_rec.phone_number || ‘ is skipped’);
goto next;
end;
dbms_output.put_line(‘Number '|| v_rec.phone_number || ‘ is available’);
commit;
v_count:=v_count+1;
end if;
if v_count=10 then
goto out;
end if;
end loop;
<<out>>
end;
7

8. Why it is GREEN ?
A costly solution may request a new column to be added to the
existing production DB table ( which is obviously bad idea), or it
may generate temporary DB data which keeps growing thus a
clean-up job must be added to production’s operation schedule,
or it may hire too complicated techs to resolve concurrency
problem … resulted stability will be questioned.
However with our green solution, apart from the necessary
Service Module change (which implements the logic described
above ), only one new DB table is added to the production, and it
does NOT need initialization or cleanup hence causing no extra
maintenance cost. More importantly, the resulted stability is
predicted as the logic is simple and natural.
8