I've been an observer on the board for a few weeks but this is my 1st post
OK - to my question...
I currently have a JTable displaying search results for bookable rooms. My GUI permits only single-row selection and therefore any given client can book only one room at a time. Is this too restrictive -i.e. am I likely to lose marks for this ?
The other possibility is to allow multiple row selection which means one client locking multiple records and would complicate matters quite a bit. To prevent deadlock, I think locks would have to be acquired in a standard order. Also what would you do if you tried to book 4 rooms where one record was locked (i.e. being booked by someone else) and the others were not - should the 3 available rooms be booked or should the system warn you that your entire request might not be met. Sounds like a can of worms.
Many candidates only allow a single record to be booked at a time - you will not loose marks for doing this.
However doing this is a design choice, therefore you should document it in your design choices document. Let the assessor know that you have considered this and considered the alternatives, and let them know why you chose one over the other.
You should also document this in implementation comments (not Javadoc comments) in your source code. Be kind to whoever is reading your code (whether it is the assessor in this case or somebody maintaining your code in real life) - don't make them try to guess your reasoning, make it obvious next to the code.
Personally I agree with your "can of worms" statement. The issues you mentioned can all be handled, but I believe that handling them is going beyond the scope of the assignment. To handle them you are going to have to make a large number of decisions on behalf of the client - in real life you would probably have to ask the client whether they want multiple simultaneous bookings from one CSR, and if they say yes (which they probably will), you would then start raising all the other issues - renegotiating your price or expected job timeframe. You should not allow scope creep just because you feel it is a good idea.