Bram Pramono wrote:Also my locking mechanisme assignment forced me to use lock cookie as an authentication key for the lock. This means that a client trying to update or delete a record need lock this first then update or delete. So my GUI for client work as follow :
1. A client tries to book a room. Click on "Book" button -> check if record is locked, if not -> lock record -> GUI gives popup window to fill in consumerID
2. The client fill in the customerID and press enter. Check if input valid, if yes -> send customerID and update record -> unlock record
So the scenario I imagine is that the client will always lock at start before starting to edit or delete. The editing and deleting will take a few seconds or minutes before it is committed. If this happens, and I let other clients, who want to access the same record, wait until the first client finished. It will take a long time for the other clients to access the same record. This is actually the main reason why I feel strongly that waiting is not an option.
PS: Example of escaping "must" requirement I found in the forum is that many people implement 3-tier architecture instead of 2-tier
Important Note About Automatic Failure
Where this document uses the word "must" an absolute requirement is being described. If you fail to adhere to such a requirement, your assignment will be failed automatically, and without further evaluation. It is therefore imperative that you pay close attention to any statement using the word "must" in this document. Portions of your submission will be analyzed by software; where a specific spelling or structure is required, even a slight deviation could result in automatic failure.
Switching from electric heat to a rocket mass heater reduces your carbon footprint as much as parking 7 cars. Tiny ad:
Free, earth friendly heat - from the CodeRanch trailbosshttps://www.kickstarter.com/projects/paulwheaton/free-heat