Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Approach to test locks

 
Luiz Reginaldo Curado
Ranch Hand
Posts: 108
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi!

Several people are concerned about the lock approach in the assignemt. I believe that a massive test in the database (using some thousand of concorrent threads) could validate if the approach works or not. I also believe that Sun do something like this to grade our assignments.

So, this is the question: what can we put in some test threads to validade our approach?
 
Luiz Reginaldo Curado
Ranch Hand
Posts: 108
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok, Let's put some sugestions....

- Start about 100 ~ 200 threads
- Each thread can book / unbook / delete / create records
- The specific operation is given by a random choice
- Each thread perform a number of 10.000 operations (using a for loop, and maybe a Thread.sleep() )

So, what I think is that if the database survive to this test, then your locking strategy is good.

What you ranchers think about this???
 
Daniel Bryant
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Luiz,

I've done something similar to what you have suggested - I think if your database survives this many concurrent accesses you can be reasonably sure your file access is safe and you have avoided deadlocks.

In order to further analyse what was going on I have also recorded all the expected and actual successful operations (i.e. every attempt to create a record, and every sucessful create), and every exception and lock contention . I found I could tweak my lock code to reduce what was originally a shocking figure for lock contentions )

I also created seperate tests in which I created a series of artifical situations. For example, I used the sleep() method to pause a series of threads to increase lock contentions, and I also simulated threads gaining and losing CPU time at unfortunate places within the code, such as just before writing a new record or releasing a lock). I also created a few tests in which hundreds of threads attempt to repeat certain operations on a single record or take part in a series of operations that could be dangerous . For example, try and have hundreds of threads deleting a random record, and only if they succeed creating a new one - the size of your DB should remain constant (mine didn't on first try of this test) This test will also show if your code reuses deleted recNos properly and doesn't write a record to an unexpected location within the file.

I hope this helps

Daniel
[ August 17, 2006: Message edited by: Daniel Bryant ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic