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'm finally done - I think! I just tested the threading model and it seemed to work well. Documentation is now done, and all I have to do is jar everything up and submit it. (I don't have any idea how to do that so I might have some ?'s on jarring and submitting later!) My current question concerns the validity of my threading test. On the client-side I made a simple loop (i = 50) that constructs a runnable object and the runnable invokes the RMI object and reserves a seat. The remaining seats after 50 iterations of that loop is correct. Is this test sufficient to test the correctness of my threading model? Or do I need to do something to insure that the run method is invoked on the client-side at exactly the same micro-second? If so, what - I don't have any idea how to do this. Thanks for your help! Kirk Maze
Sun Certified Java Developer<br />Sun Certified Java Programmer
Or do I need to do something to insure that the run method is invoked on the client-side at exactly the same micro-second? If so, what - I don't have any idea how to do this.
Testing with just one client is obviously not enough, -- it never tests your locks. I recommend writing a test case that creates 20 threads (each representing a remote client). Each thread will connect to the server and book a seat on the same flight, 100 times in a loop. When all threads are done, your seat count for that flight should be reduced by exactly 2000. Eugene.
Joined: May 14, 2002
I guess I wan't clear - each of these iterations creates a new thread and each of the threads asks for a unique server-side connection object, and each of these objects requests one seat on the same flight. So I know that we're actually multithreading. What I'm unsure of is the response time of the machine itself. It might be possible that it is doing the work so quickly that each thread is done before the next one kicks off, and so my locking scheme is moot and not really being tested. I'd be more comforable if I knew for sure that at least two (and preferably all!) of the 50 threads I created, kicked off at exactly the same micro-second, so the LockManager had to work properly or there'd be abberations. All that said, I appreciate your feedback Eugene,and I'll give it a try. It's essentially the same test I ran before, but with 20 clients and 100 seats instead of 50 clients and 1 seat. Thanks!
Kirk, Another simple test you can do is put either a Thread.sleep() or a System.in.readLine() in between you calls to lock() and unlock(). Then start up two raphical clients and book a seat on the same flight, and see that the second one blocks appropriately until after the first one calls unlock. The first client should show n-1 seats, and the second should show n-2, and if you refresh the data on the first client, it should show n-2 as well.
Joined: May 14, 2002
OK - it worked! I guess my ThreadQue, which I had no real confidence in, is doing his job. In the event I don't have other questions to post later, I want to thank Eugene, Mark and Peter. While I haven't posted much, I've read the majority of what the three of you have written. As a direct result, my design is good (although I never figured out how to incorporate Unreferenced in a Remote object so the compiler wouldn't complain!), it apparently works, it's much better than I could have done without you guys, and I'm proud of it! Thanks again. Kirk Maze