I tested today with a testclass spawning off 10 threads each thread booking 1 seat 10 times. I had four of this running booking 400 seats in total on the same flight. And yes, the deduction was 400, seems ok and threadsafe to me (during the time this 40 thread were booking i had the client window upp booking seats on other flights, no problems).
Then I read this:
<H3>Writing the Data Server</H3>
<P>You must create a data server that will accept multiple concurrent network connections and allow them to interrogate and manipulate the database. Because multiple concurrent connections may exist, you must make both your server and the suncertify.db classes threadsafe. You may implement your threaded server in more than one class if you choose. </P>
<H3>Writing Data Client</H3>
<P>To connect with your server, you should create a client program. This implementation should include a class that implements the same public methods as the suncertify.db.Data class, although it will need different constructors to allow it to support the network configuration. </P>
I can't say that I implemented any code to make my server and the suncertify.db classes threadsafe (a few methods are, as you know, synchronized).
I've a remote class who delegates to the Data class and to a locking mgr, is that making the server and db classes threadsafe or have I in fact more work to do on this ?
Anyhow, I then try to book the same flight on some other client instances, and finally click the Ok button so that Traffic Cop can complete.
Of course, there are other fun games I can play, such as terminating the Traffic Cop process while everybody else is waiting for him/her to finish his/her business (have to be gender correct here in the U.S. )
that went basically past the wicket-keeper, I think. Unless you mean that I've been testing the locking mechanism only. Your fun & games will freeze the clients and that threadsafe then beeing able to complete the booking even though some other process crapped out ? I have a thread in the locking mgr cleaning up long held rcd lock, does that qualify ?
My server, incidentally, is just a special case of my client (the server connects to the database "locally," rather than remotely, as with "normal" clients), and so I can also book flights from the "server" (which can be thought of as an "administrator-mode" client).
When I dismiss the dialog box, Traffic Cop finishes his business, and then all the waiting threads are "off to the races" trying to finish theirs (possibly running into problems such as InsufficientSeatsException).
The Unreferenced interface (that is exhaustively discussed in this forum) handles the case of the murdered Traffic Cop- after 30 seconds, the server buries the Traffic Cop, cleans up the blood, and then everybody goes merrily about his/her business.
I followed this discussion because I think I have a similar implementation like you Torgny. Maybe I am too dumb but could you please give me a clear explanation if "our" implementation is valid.
I just finished the whole implementation and created some test threads and everything worked just fine but I am not sure if I did it correctly.
Thanks for your advice in advance.
my concern here was the term threadsafe. Coming from an environment where I've used no thread (AS/400) it was suddenly unclear. Especially as it is stated in the requirements. When doing this test I added a sleep for up to 5000 ms (a Random object) after the call to lock. That meant that all 40 thread was competing for locks. I could see that since I had printouts from the server saying who and what record was locked and unlocked. And also during the slowed down threads where "hammering away" at the server I used the client window to check the progress and book additional seats on other flights. I have previously tested that a lock where the client goes away is taken care of by the lock mgr internal thread so that no locks can exist for ever. I've done this test a few times (had to do it again since I did some changes during the weekend) and feel comfortably with the implementation as it is today. The printouts from the server (added record lock for rcd 1 should be followed by a remove ditto) showed that the lock mgr worked as intended and I hope thereby I've accomodated for "threadsafe".
If this makes it any clearer... hope so.
thanks for your explanation. I am still a little doubtful about my implementation, although I actually created a similar test environment and everything went smoothly, because it took me just 6 days to code the whole thing. My concern is that I missed something general because it took me just a couple of days and it instantly worked, which is really not normally how it goes.
Well I guess I will spend the next week testing my code to eliminate any hidden errors.