• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Test Locking Procedures

 
Cindy Carney
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi everyone! It took me a couple of days to implement the Data class fully, and another day to work up a test harness for it. I believe I have all the bases covered - I run about 28 tests total, checking to make sure success and failures both happen when expected.

The question I would like to pose to you all, is whether or not my multithreaded testing is sufficient.

  • For create, I created 500 threads, and had them all create 5 records.
  • For update, I created 500 threads, and had them all hammer the same record at once, updating the record 5 times.
  • For read, I created 500 threads, and had them all read the same record at once, 5 times..
  • For a general mix, I created 500 threads, and had they all apply CRUD logic 5 times - create, read, update, and delete.


  • I didn't encounter any hangs, so I believe everything is OK. I also reversed the indices, to test with 5 threads doing 500 operations, and that ran as well, but faster.

    Can you think of a multithreading test I may have overlooked?

     
    Carlos Morillo
    Ranch Hand
    Posts: 221
    Java Python Scala
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Cindy,

    I would strongly recommed you check the SCJD Forum FAQ and look for Roberto Perillo's Data Class Test which is excellent to test all the Data class methods and locking.

    HTH,

    Carlos.
     
    Roel De Nijs
    Sheriff
    Posts: 10666
    144
    AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Cindy,

    On the one hand your Data class must be thread-safe/ handling multiple concurrent requests without corrupting your database file. So you have to make sure for example that positioning your file pointer and writing a record is done in 1 automatic operation. This can be tested by creating, updating and deleting records and after the whole test just reading your database file. If it doesn't throw an unexpected IOException (like an EOFException) you'll be just fine.

    On the other hand you have to make sure what happens when 2 (or more) threads compete for the lock on the same record, and it gets really interesting when threadA tries to delete record 1 and threadB wants to update record 1. It's this scenario, executed in a certain order that can (and will) cause a deadlock situation. Like Carlos already indicated, Roberto Perillo's DataClassTest is the best possible tool for testing your Data class.

    Kind regards,
    Roel
     
    Cindy Carney
    Ranch Hand
    Posts: 57
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Roel De Nijs wrote:Hi Cindy,

    On the other hand you have to make sure what happens when 2 (or more) threads compete for the lock on the same record, and it gets really interesting when threadA tries to delete record 1 and threadB wants to update record 1. It's this scenario, executed in a certain order that can (and will) cause a deadlock situation. Like Carlos already indicated, Roberto Perillo's DataClassTest is the best possible tool for testing your Data class.

    Kind regards,
    Roel


    Good point - I will add that test to the mix. Thanks for the heads up!
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic