Hi All, Just wondering if it is possible to dispute a failed assignment. According to Sun, my record-locking is not thread-safe, however I cannot get 2 threads to obtain a lock on the same record, as they say is possible with my solution. Anyone know if possible/how to dispute results? Thanks, Aaron
It is possible to dispute. But I do not know right off what process needs to be taken. In your instructions.html there should be an email at the end of the instructions. I'm sure someone from this email can at least answer your question.
Hi Aaron, You could try asking firstname.lastname@example.org to have someone review that decision, but you may have quite a long wait and not get any better results. There have been enough people who have failed and then passed after Sun did an internal review that it is worth while you asking for this. But you need to make 100% sure that your code is thread safe. If possible, ask another Java programmer to review it. Unfortunately this is one of the hardest areas to dispute. The examiner does not have to prove that the locking code is faulty, just that there is a theoretical chance that it might fail. And that could be a problem: your tests may not have triggered the exact conditions which could cause two threads to gain the same lock. Regards, Andrew
Thank you both for your responses. Andrew, can you give me your advise as to what is a "reasonable" test of my locking strategy. For example, can you (or anyone else here) advise of a "fool-proof" way to ensure that my code is thread-safe? I have performed the following tests: 1. Issued up to 100 concurrent lock requests for the same record using separate remote connections, with debug statements on each successful lock, each wait, and each unlock showing the current Thread and requesting object ID. This shows that it was never possible to obtain a lock on a locked record. 2. Issued up to 100 concurrent lock requests for the same record using 1 remote connection, with debug showing that a request for a lock on a locked record by the requesting objectID returns with no action. Assuming I do not have any other Java programmers around me to review my code, what other tests / advice can you offer? Any advice is much appreciated. Thanks,
Matt R. Hansen
Joined: Sep 05, 2001
Just as a side note, I have emailed email@example.com with a question and I was able to get a response. I was unclear on the instructions as to whether the client needed the ability to tell the server where to find the db file. Here was their response:
Assume that in networked mode, the server and the database file are on the same machine. In this mode, In local mode, the gui and the database are on the same machine. The client does not need facilities to tell the server where to find the database.
It was brief, but they answered.
author and jackaroo
Hi Aaron, Your tests look reasonable. The problem with testing, though, is that it is so hard to emulate what could happen in real life. That is why I was recommending a code review (which I see you have done in a separate topic). That is where the best testing can come unstuck: the tests may all appear to be successful, but there could still be a theoretical flaw with the locking (which we can talk about in the other topic). I assume that you had your 100 lock requests being issued in separate threads. But there is still a limitation on the JVM issuing those 100 threads - it can only deal with one of those threads at any given time (unless you are using a JVM which is multi processor aware on an OS that is multi processor aware on multi processor hardware (Solaris 64?)). If you do have multiple processors, then you could try splitting those threads amongst multiple JVMs. Or better yet - have multiple physical client machines trying to request the same lock from the one server machine. Just to clarify: your failure was due to "locking" not being thread safe? So it was specific to the lock / unlock code, and not to the server in general? Another common test is to try to update multiple records simulaneously. Create 20 threads which update the first 20 records, setting the number of seats equal to the logical thread number (so the first thread you start will set the number of seats in record number 1 to 1, ... the fourth thread you start will set the number of seats in record number 4 to 4 ...). It is important to try and get all the threads starting their modifications simultaneously - so you need to make the connections and do any other configuration then go into a wait until all other threads are all ready, then notify all of them so that they all start work at the same time. At the end of the run, verify that your database does contain '1' in record 1, '2' in record 2 ... Regards, Andrew [ December 09, 2003: Message edited by: Andrew Monkhouse ]
Joined: May 10, 2002
Thanks Andrew... I will continue with this post in my other topic from now on. Regards,