Hello, According to the B&S document, the following is stated regarding "Locking":
Your server "must" be capable of handling multiple concurrent requests, and as part of this capability, "must" provide locking functionality as specified in the interface provided above. You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server. Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, consuming no CPU cycles until the desired resource becomes available.
Based on the statement above, I have met two of the required "musts" stated above. But the last statement concerns me the most, "Any attempt to lock a resource...". No where in this statement does it state a "must". Do I have to implement a "wait()" and/or "notifyAll()" to avoid an automatic failure? Has anyone passed the assignment without using wait() and notifyAll()?
My application notifies the user if a record is already locked, with a message: "This record is already locked. Please select another contractor or again later.". This approach does not consuming any CPU cycles by immediately returning an error message to the user. If this is not an automatic failure, I'm assuming worse case senario is that I lose a lot of points on the Locking section if I don't implement wait() and/or notifyAll()?
Is stating this understanding in the design "choices.txt" document sufficient enough? Can someone please help me with this requirement as I'm ready to submit my assignment but am VERY concerned this might fail me?
Shannon - there's a large difference between locking in the context of thread synchronization and 'locking' a record.
I believe the requirement is to protect the booking functionality WITH locking functionality. I.E. when two users want to book the same business at the same time, the first one in gets to do it while the second one must block and wait until the first one is done with his booking operation. Only then should the second one's request be able to proceed, evaluate the record, see its booked, and then notify the user.
The key issues around any shared resource (for example a database) are preventing two or more threads from updating the same data at the same time. This is what I believe the locking functionality is supposed to do. I would imagine that if you didn't implement this you would lose significant marks in the Threading section. Threading is worth 80 points out of 400; it's tied for the largest number of marks in conjunction with General Considerations. It's really not a good idea to let things slide in this section; doing so could cost you your cert :/
My 2c Jeremy
McFinnigan? Never heard of him. Nobody here but us chickens...<br /> <br />SCJP for Java 1.4<br />SCJD for Java 5.0
Joined: Jul 03, 2003
Hi Jeremy, Thanks for your reply. Well, I was hoping for a different response. Hee, hee, hee, I was hoping to avoid adding multi-threaded code...cuz now I have to change my GUI too. However, it was better to ask then regret it later.