Test Locking Procedures

[Cindy Carney]

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]

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]

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]

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!