Hi all, I am working on B&S version 2.2.1 and have a few questions about booking of contractors. At the moment, I have a table of contractors from the database, and a client is able to select a particular row and click 'Book', which then generates a random long (representing the CSR number), and updates the table, displaying this long in the 'Owner' column. The book() method uses a lock(), update(), unlock() sequence of operations, synchronized on a hashmap of currently locked records.
My question is this -- are other clients able to book contractors which are already booked? So if Client1 books contractor 5, is Client2 then allowed to overwrite this booking? If not, should a message be shown to the client that the contractor is already booked???
I have assumed that it is not allowed to book an already booked client. What would be the purpose of booking if the booking can be overwritten?
I made the book functionality perform the sequence lock - read - update - unlock, where the read call is to verify that the contractor is not booked yet. If the contractor is already booked, the booking is aborted of course.
IMHO, this sequence is the primary reason why we need to have lock/unlock methods to begin with: only when the record is locked can we be certain that no other client has just booked the contractor.
which then generates a random long (representing the CSR number),
I am slightly off topic, but I noticed this and wondered why you decided to generate a random number instead of letting the user enter one in. My instructions state
Note that for this application, you should assume that customers and CSRs know their customer ids.
I would hate to see you lose any unneccessary points.
“Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.” - Rich Cook
All of the world's problems can be solved in a garden - Geoff Lawton. Tiny ad:
RavenDB is an Open Source NoSQL Database that’s fully transactional (ACID) across your database