A green solution to solve a race condition problem


Published on

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.

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

A green solution to solve a race condition problem

  1. 1. A Green Solution that fixed a real-life Race Condition problem by Kai Zhou 1
  2. 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. 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. 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. 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. 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. 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. 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