RE: Untested Developer Code - lack of concurrency testing

  • From: Amar Kumar Padhi <amar.padhi@xxxxxxxxx>
  • To: <kylelf@xxxxxxxxx>
  • Date: Wed, 13 May 2009 10:05:50 +0400 (GST)

The most problematic stuff I have come across is lack of developers ability to 
think from concurrent session or multiple sessions running the same code. Most 
developers design and test code from a single session, not analyzing the 
outcome if the code is executed in parallel for the same set of data. In my 
case this has resulted in deadlock and even duplicate data processing. Imagine, 
two users running the same accounting process that generates duplicate Entries 
in the system and then you have to dig and sort the issue. Yes this also 
results in arguments whether the developers missed something or the users are 
disorganized. I make use of custom designed application locks as well as 
dbms_lock to prevent such issues. Developers now follow it as a standard. 
Haven't seen any more issues in this area. Users are also happy as the 
application prompts who is holding the lock before they even start processing 
the data. 

2) the other one is order of columns in a composite index, as well as the 
choice to make the right index on the right columns that does not conflict with 
already existing index. 

That is all I can immediately think of and jot down. 

Thanks! 
Amar 
Www.amar-Padhi.com 

-original message-
Subject: Untested Developer Code - lack of concurrency testing
From: "kyle Hailey" <kylelf@xxxxxxxxx>
Date: 12-05-2009 19:17

with one user and it runs fine and then gets put into production and
only to hit a huge performance snafu.   I'm putting together a demo on this 
kind of situation and was
thinking of some examples. One example that came to mind is a Nesedt
Loops join that hammers the root node of an index. Might work fine for
one user, but when multiple users start running it, the query runs
into cache buffers chains latch issues with the high concurrency
access to the index's root block which might be resolved by doing a
hash join or moving the lookup table to a hash cluster for example.   Wondering 
if anyone else had good examples of developer code that
worked fine with one user and broke in the multi user production
environment.
X-archive-position: 17586
X-ecartis-version: Ecartis v1.0.0
Sender: oracle-l-bounce@xxxxxxxxxxxxx
Errors-to: oracle-l-bounce@xxxxxxxxxxxxx
X-original-sender: kylelf@xxxxxxxxx
Precedence: normal
Reply-to: kylelf@xxxxxxxxx
List-help: <mailto:ecartis@xxxxxxxxxxxxx?Subject=help>
List-unsubscribe: <oracle-l-request@xxxxxxxxxxxxx?Subject=unsubscribe>
List-software: Ecartis version 1.0.0
List-Id: oracle-l <oracle-l.freelists.org>
X-List-ID: oracle-l <oracle-l.freelists.org>
List-subscribe: <oracle-l-request@xxxxxxxxxxxxx?Subject=subscribe>
List-owner: <mailto:steve.adams@xxxxxxxxxxxx>
List-post: <mailto:oracle-l@xxxxxxxxxxxxx>
List-archive: <//www.freelists.org/archives/oracle-l>
X-list: oracle-l

Best
Kyle Hailey

http://oraclemonitor.com/
--
//www.freelists.org/webpage/oracle-l



--
//www.freelists.org/webpage/oracle-l


Other related posts: