aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes NX: B&S a must requirement for locking...HELP!?! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "NX: B&S a must requirement for locking...HELP!?!" Watch "NX: B&S a must requirement for locking...HELP!?!" New topic
Author

NX: B&S a must requirement for locking...HELP!?!

Shannon Sims
Ranch Hand

Joined: Jul 03, 2003
Posts: 197
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?

Thank you in advance for everyone's feedback.
Jeremy Botha
Ranch Hand

Joined: Feb 16, 2005
Posts: 125
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
Shannon Sims
Ranch Hand

Joined: Jul 03, 2003
Posts: 197
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.

-Shannon
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: NX: B&S a must requirement for locking...HELP!?!