This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I have been thinking on how to automate the booking of the same flight at the same time. I want to test the concurrent use of the datanbase.Any ideas?
Create a test class which spawns 20 thread, each thread representing a remote client. Let each thread reserve 1 seat on a particular flight, 100 times in a row. If at the end of the run the seat count is reduced by exactly 2000 seats, you pass. Eugene.
If at the end of the run the seat count is reduced by exactly 2000 seats, you pass.
However if there wern't 2000 seats to begin with, and you end up with 2000 seats being booked then either you failed or your test scenario wasn't quite right You probably need to test the locking mechanism, which would require you to have the business logic in the threads - lock a record / confirm number of seats available / decrement count / unlock record (if you have implemented the business logic at the client side not the server side). You could then try starting with an initial seat count of 3999, reducing by two seats at a time. At the end of the run, one of your threads should have complained that there were not enough seats available, and you should have one seat left in the table. The tests can get far more involved than this as well
Hi Larry, You should try to limit your testing to one area only. So your first tests should just be for databse concurrency with local access. The next sets of tests should test via your network methodology, so your tests should call the same RMI classes and methods, or the same Serialised Sockets classes and methods as your real application. Unless you are using client machine specific data in your database (or locking) methods, you should not have to test from different machines. You should still only be testing your database concurrency at this point. The testing from multiple machines is a seperate set of tests, unrelated to the database concurrency issues. The exception is as I mentioned before - if you are using connection data in your databse access or locking, then you would then have to test it (e.g. if you were using sockets and decided to use the client port number as unique ID (really bad idea) then you would need to test networking as part of your tests. You do need to test the entire deliverable later to make sure that they are not tied to specific machines (so have the server on one machine & the client on another), and test the client on as many different operating systems as possible. Regards, Andrew